Podcasts about webview

Fedora 42 and Ubuntu 25.04 are here—We break down what's new, what stands out, and what we love most about each release.Sponsored By:Tailscale: Tailscale is a programmable networking software that is private and secure by default - get it free on up to 100 devices! 1Password Extended Access Management: 1Password Extended Access Management is a device trust solution for companies with Okta, and they ensure that if a device isn't trusted and secure, it can't log into your cloud apps. ConfigCat Feature Flags: Manage features and change your software configuration using ConfigCat feature flags, without the need to re-deploy code. Support LINUX UnpluggedLinks:

To celebrate my birthday we're going to hell! Again...

In this potluck episode of Syntax, Wes and Scott answer your questions about the future of JavaScript frameworks, building custom authentication systems, limiting API access, using Caddy server proxy for local development, component props in JSX, structuring a relational database, and more! Show Notes 00:00 - Welcome to Syntax! 01:48 - Brought to you by Sentry.io 04:37 - The future of JavaScript frameworks 09:09 - How to use Caddy for local development SvelteKit Vite 14:27 - When to use an API Strapi 17:38 - Where does Scott get his amazing t-shirts? Sentry.shop Syntax Snack Pack 21:33 - Best screwdriver for kids toys PicQuic Sixpac Plus LTT Screwdriver 24:31 - Strategies for database design MongoDB Prisma 30:21 - Do we need frameworks? 796 - Do We Need JS Frameworks × Are You Over-Engineering? × Webview vs Native Frontend Masters 32:19 - Best tech stack for building a basic login system 336 - How To Build Your Own Auth 37:56 - Syntax video episodes 40:25 - Component props in JSX 45:26 - Sick Picks & Shameless Plugs Sick Picks Scott: Loop Quiet Ear Plugs Wes: Gecko's Toes Water Hose Rack Shameless Plugs Scott: Syntax YouTube Channel Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Scott and Wes tackle a variety of audience questions, from the nuances of over-engineering to the energy consumption of AI LLMs. They also discuss the pros and cons of monorepos, frameworks, and the ever-important question: Do you really need to learn all the developer tooling? Show Notes 00:00 Welcome to Syntax! 00:41 Brought to you by Sentry.io. 01:07 Challenges around a resume playback function. 05:56 Why use Google Forms for Potluck questions? 07:57 What constitutes over-engineering and how to avoid it. 13:28 Webview vs native component based mobile apps. 18:06 Running and managing monorepos. 20:59 Energy consumption of AI LLMs vs static web content. A guide to LLM inference and performance. From Words to Watts: Benchmarking the Energy Costs of LLM Inference. 25:19 Why do we need frameworks? Frank M Taylor Blog Post. 33:05 Handling ad-blockers blocking Sentry and other tools. Syntax GitHub. 38:25 Creating sites without JavaScript. 42:49 Do I really have to learn all the various developer tooling? Wes Bos Tweet. 44:47 What are the best ways to network and meet other developers? 50:16 Sick Picks & Shameless Plugs. Sick Picks Scott: Tweek App/ Wes: Rain-X Waterless Car Wash. Shameless Plugs Scott: Swag Store. Wes: Audio Player Updates. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Гость из 2ГИС — Анастасия Золотых, QA-лид продукта Отелло — сервиса по поиску и бронирования отелей в России.О чем болтаем?Пытаемся развести холивар на тему два-дубль-two ГИС. Узнаем, как в карты попадают самые свежие тропинки, а в Отелло — новые отели. Обсуждаем процессы, которые помогают одновременно релизить на разные платформы. Выясняем, как работает ферма устройств в распределенной команде, и почему ради хорошего результата надо со всеми дружить.Таймкоды:00:35 О чем болтаем 1:07 Как правильно называется компания 2ГИС 4:45 Чем занимается Настя в 2ГИС 5:43 Что делает сервис Отелло, и на каких платформах работает 6:17 Как появился Отелло 7:33 Почему карты по-разному работают в разных регионах 10:41 Как отели появляются на картах 12:08 Есть ли разделение команды по платформам 13:28 Как добиться того, чтобы команда работала на всех платформах 16:29 Как выкатить релиз одновременно для разных платформ 17:49 Планирование релизов 19:28 Секреты выпуска качественного продукта 25:07 Инструменты для WebView, использование фермы 28:41 Синхронизация распределенной команды 32:09 Специфика разработки Отелло 35:31 Особенности работы с отелями напрямую 37:31 Как обеспечить качество интеграций 40:30 Ручной труд vs автоматизация 42:20 Проблемы с затаскиванием новых подходов 45:42 Про работу фулстек-QA и дружбу 54:02 Фишка качества Насти 56:30 БлицСсылки:Книга о процессах Shape Up: https://basecamp.com/shapeup/shape-up.pdfМемы про 2ГИС: https://daily.afisha.ru/infoporn/26467-dvagis-tugis-ili-dublgis-kak-nazvanie-2gis-svodit-polzovateley-s-uma/Подробнее почитать о внутренней кухне 2ГИС и том, как наполняются и рисуются карты, можно в блоге на VC https://vc.ru/s/company-2gis-83849 и на Хабре https://habr.com/ru/companies/2gis/articles/Как мы создали Отелло: https://dzen.ru/a/ZWCnnq8iIVBReKydКрутой доклад о сверхбыстрой доставке фич в Отелло: https://www.youtube.com/watch?v=ULHNaP_P0xwПрезентация сервиса Отелло: https://youtu.be/WDhVkjHsROo?si=mYc8I-BrtQspsAIHКанал QA Tinkoff в Телеграме: https://t.me/qa_tinkoff Канал IT's Tinkoff в Телеграме: https://t.me/itstinkoff Больше про карьеру в IT в Тинькофф: https://l.tinkoff.ru/about-it-career

We released episode one of this podcast on June 11, 2012. Now, more than a decade later, we're celebrating the 500th episode of our show. In honor of this milestone, Victoria, Will, and Chad caught up with each of the past hosts of the show: Ben Orenstein, Chris Toomey, and Lindsey Christensen. We chatted about what they're up to now, what they liked and learned from hosting the show, their time at thoughtbot, and more! Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. WILL: And I'm your other host, Will Larry. CHAD: And I'm your other host, Chad Pytel. We released episode one of this podcast on June 11, 2012. Now more than a decade later, were celebrating this: the 500th episode of our show. In honor of this milestone, Victoria, Will, and I caught up with each of the past hosts of the show: Ben Orenstein, Chris Toomey, and Lindsey Christensen. We chatted about what they're up to now, what they liked and learned from hosting the show and their time at thoughtbot, and more. First up: Ben Orenstein. Ben was the very first host of the show back in 2012 when he was a developer at thoughtbot. He is now the co-founder and Head of Product at Tuple, a remote pair programming tool for designers and developers. Ben, it's great to talk to you again. It's been a while since you and I talked. How have you been? BEN: I've been decent, yeah. It's fun to be back to my roots a little bit. I told some folks that I work with that I was coming back to the pod for the 500th Episode, and they were stoked. So, it's kind of a treat to get to be on these airwaves again. CHAD: What have you been up to since you left this show and thoughtbot? BEN: Well, I started a company. So, I was at thoughtbot for a while; I think it was seven years. And I eventually sort of struck out to start my own thing–had a false start or two here and there. And then, I ended up starting a company called Tuple, and we still exist today, fortunately. Tuple is a tool for doing remote pair programming. We started off on macOS and then wrote a Linux client. And we're launching a Windows client now. But it's sort of, like, screen sharing with remote control for developers who are actually writing code and want to have great, low latency remote control and who care about screen share quality and that sort of thing. I started that about five years ago with two co-founders. Today, we are a team of 11, I think it is. And it's been going well. Our timing was really great, it turned out. We launched a little bit before COVID. So, remote work turned into a lot more of a thing, and we were already in the market. So, that helped us a ton. It was quite a wild ride there for a bit. But things have calmed down a little lately, but it's still fun. I'm, like, really enjoying being a co-founder of a software company. It was what I've always sort of wanted to do. And it turns out it actually is pretty fun and pretty great. Although there are, of course, the ups and downs of business ownership. It is never quite as calm or relaxing as being an employee somewhere else. CHAD: You started Tuple instigated by...full disclosure: thoughtbot's an early customer of Tuple. We're still a customer. We use it a lot. BEN: Woo-hoo. I appreciate that. Thank you. CHAD: If I remember right, you started and were sort of instigated to create Tuple because there was a prior product that then Slack bought, and then it started to degrade. And now, it no longer exists in the same way that it did before. BEN: Yeah. So, there was this tool called Screenhero, which I actually started using -- CHAD: [inaudible 02:14] BEN: Yeah, first at thoughtbot. Some other thoughtboter introduced me to it, and we would use it for pair programming. And I was like, oh, this is nice. And then yeah, Slack kind of acqui-hired it and more or less ended up shutting the product down. And so, there was this gap in the market. And I would ask my friends, I would ask thoughtboters and other developers, like, "What are you using now that Screenhero is gone?" And no one had a good answer. And so, after a while of this thing sort of staring me in the face, I was like, we have to try to solve this need. There's clearly a hole in the market. Yeah, so we were heavily inspired by them in the early days. Hopefully, we've charted our own path now. But they were definitely...the initial seed was, you know, let's do Screenhero but try to not get bought early or something. CHAD: [laughs] How did you or did you feel like you captured a lot of the Screenhero customers and reached them in those early days? BEN: I think so. The pitch for it was sort of shockingly easy because Screenhero had kind of blazed this trail. Like, I would often just be like, "Oh, we're making a thing. Do you remember Screenhero?" And they'd go, "Oh yeah, I loved Screenhero". I'd be like, "Yeah, we're going to try to do that." And they'd be like, "Nice. Sign me up." So, it for sure helped a ton. I have no idea what percentage of customers we converted. And they were a pretty large success, so probably a small fraction, but it definitely, like, made the initial days much easier. CHAD: Yeah. And then, like you said, COVID happened. BEN: COVID happened, yeah. I think we had been around for about a year when COVID hit. So, we were getting our feet underneath us. And we were already, like, the company was already growing at a pretty good rate, and we were feeling pretty good about it. I don't think we had quite hit ramen profitable, but we were probably pretty close or, like, flirting with it. Yeah, the business, like, I don't know, tripled or quadrupled in a matter of months. We had a few big customers that, like, just told everyone to start using Tuple. So, we had, like, thousands and thousands of new users kind of immediately. So, it was a crazy time. Everything melted, of course. We hadn't quite engineered for that much scale. We had a really rough day or so as we scrambled, but fortunately, we got things under control. And then had this, like, very nice tailwind. Because we started the company assuming that remote work would grow. We assumed that there would be more remote developers every year. And, you know, it's probably maybe 5% of dev jobs are remote or maybe even less, but we expect to see this number creeping up. We don't think that trend will reverse. And so, COVID just, like, it just yanked it, you know, a decade in the future. CHAD: You haven't tripled or quadrupled your team size, have you? BEN: No. Well, I mean, I guess, I mean, we started as 3, and now we're 11, so kind of. CHAD: [laughs] Yeah, that's true. BEN: Expenses have not grown as fast as revenue, fortunately. CHAD: That's good. That's basically what I was asking [laughs]. BEN: Yeah, yeah. We're still a pretty small team, actually. We have only, like, four or five full-time engineers on the team at the moment, which is kind of wild because we are now, you know, we have three platforms to support: Linux, Windows, and Mac. It's a pretty complicated app doing, like, real-time streaming of audio, webcams, desktops, caring about OS-level intricacies. So, I think we will be hiring more people soon, although we haven't said that for a long time. We sort of have always had a bit of a hire-slow mentality to try to get the right team members and, like, feel a real pain before we hire someone into it. But we have been getting a bit more aggressive with hiring lately. VICTORIA: Well, I really appreciate Tuple. I installed it when I first started working here at thoughtbot. And we have random pairings with everyone across the company. So, I'll randomly get to meet someone halfway across the world who's working on similar projects. And I think they really enjoy that I have a tool they like working to share what they're working on. So, I want to thank you for that. And I'm curious about when you really started to scale during COVID, what were some of the technology architecture trade-offs you came across, and where did you land with it? BEN: Well, we got fairly...I don't know if it was lucky, but we...for a long time, for years, even through COVID, maybe the first four years of the company, all Tuple calls were purely peer-to-peer. And there was no server that we owned intermediating things. This was, like, kind of one of the keys of, like, not having expenses. The scale of revenue was we could have lots more calls happen. And it wouldn't cost us bandwidth or server capacity. To this day, still, for any calls with three or fewer participants, they're purely peer-to-peer. And this is nice for latency purposes because it just...we can find the most direct path to the internet between two people. It's also nice from our cost perspective because we don't need to pay to send that data. And that was hugely useful as call volume went up immensely. Didn't have to worry too much about server load and didn't have to worry too much about bandwidth costs. CHAD: Today, is there a central service that makes the initial connection for people? BEN: Yes, yeah, yeah. So, there is a signaling server. So, when you launch the app, you sign in, and you see, like, oh, which of my co-workers are online? So, there is actually a Rails app that handles that, actually, increasingly less the Rails app. We have now...I think it's a Go service that actually manages all those. I'm further and further from the code every year. Some of the technical questions might be a little bit beyond me, or I might have slightly out-of-date info. But back to the architecture question for a second, we did a pretty big refactor when we decided to go from just being a Mac client to supporting other platforms, where we split out a cross-platform real-time communication engine written in C++ so that we could use that for all of the heavy lifting, all the managing of the connections, and the tricky bandwidth estimation, and all this stuff, and use that across different platforms. And so, today, you have the cross-platform engine, and then on top of that is a, like, a less specific layer for each of the operating systems that we support. CHAD: So, you mentioned you're less and less in the code these days. So, what do you spend your time doing then? BEN: It's a mix of things. These days, it's basically mostly -- CHAD: Just cocktails on the beach, right? BEN: Cocktails, yes [laughs], cocktails on the beach, appearing on podcasts trying to sound important and impressive, yeah. Mostly product work. So, right before this, I just got off a call with some folks from The Browser Company. They are some of our first alpha users for our new Windows clients. So, I hopped on the call with them and, like, watched three of them install the product and inevitably run into some bugs. And, you know, chatted through those with the engineer that was working on it, prioritized some stuff, made some decisions about what's coming up next, and what we're going to ignore. So, mostly product work these days. For the first five years of the company, I was CEO, so I was doing kind of everything: marketing, and also hiring, and also product. About two months ago, I stepped down as CEO, and one of my other co-founders, Spencer, stepped up. And so, now my focus has narrowed to be mostly just product stuff and much less on the marketing or hiring side. VICTORIA: Yeah, you mentioned that it was a little more comfortable to be an employee than to be a founder. I don't know if you could say more about that because, certainly, a lot of engineers are smart enough and capable enough to run their own company. But what really informed your choice there, and do you regret it? [laughs] BEN: I definitely don't regret it. thoughtbot was a close second in terms of wonderful professional experiences. But running my own thing has been the most interesting professional thing I've done by a big margin. It has also been more stressful. And, Chad, I don't know if you remember, I think, like, maybe eight years ago, you tweeted something like, if you want to sleep well at night, and, like, value that, like, peace of mind, like, don't start a company or something. I have experienced that. CHAD: [laughs] BEN: A lot more, yeah, like waking up in the middle of the night worrying about things. It feels a little bit like the highs are higher; the lows are lower. Being an employee somewhere, it's like, if this company fails, I know I can go get another job, right? Like, you're a developer. You're extremely employable. But as the owner of the company, if the company fails, like, a huge chunk of your net worth is gone. Like, this thing you poured your life into is gone. It's way more stressful and traumatic to have that happen, or have that threatened to be happening, or just imagine that happening. So, overall, I have found the trade-off to be totally worth it. It's awesome to make your own decisions and chart your own path. And when it works, it can work in a way that being a salaried employee can't. So, I'm happy with those trade-offs. But I think that is a good question for people to ask themselves as they consider doing something like this is, like: is that the kind of trade-off that you want to make? Because it has significant downsides for sure. WILL: I am a big fan of Tuple also. I love it. It [inaudible 10:08] easy, especially with remote work. You hit the jackpot with COVID and remote work, so kudos for that [laughs]. Was there anything...because I know from our previous companies, about over...hopefully a lot more of the good stuff than the bad stuff. But was there anything that you learned? Because you were at thoughtbot for seven years. Was there anything that you're like, oh my gosh, I learned that, and it's helped me till this day while I'm running my company? BEN: Yeah, quite a bit, actually. I think it'd be hard to tease apart exactly which lessons, but I do...so I ran Upcase for thoughtbot and also FormKeep. So, I got a chance to kind of run a small division of the company, while still being a normal employee and, like, having not much of that risk. And I think that was a really wonderful opportunity for me to, like, practice the skills that I was interested in. Just, like, how do you market a thing? How do you design a product and have it be good? How do you prioritize user feedback? There were a ton of lessons from those days that I feel like made me better at running our company when we actually took a shot at it. So, there were, like, the specific things that I learned by the work I was doing there. But then just, like, I mean, I think I am the programmer I am today because of, like, the weekly dev discussions that happened. Like, spending so much time with Joe Ferris and, like, trying to copy as much of his brain as possible, like, really, like, imprinted on me as, like, a programmer. And also, just, like, a lot of the sort of cultural things from my time at thoughtbot of, like, you should be sharing the things you're learning. Like, writing blog posts is a great use of time. Like, doing open-source work is a great use of time. And maybe you can't directly trace how doing, like, working in public or sharing information benefits the company. It's hard to, like, attribute it from a marketing sense. But if you sort of have faith that in the large, it's going to work out, it probably will. That feels like a thoughtbot lesson to me, and I think it has served us really well; where I recorded a weekly podcast for a long time called The Art of Product. I'm recording a new podcast called Hackers Incorporated with Adam Wathan of Tailwind fame. And I don't ever think, like, hmm, how many new leads do we think we get per episode, and how many hours has that taken? What's the ROI? I just have this sort of reflex that I developed from thoughtbot time of, like, you should be putting stuff out there, or you should be giving back. You should help other people. And that will probably help your business and make it work in the long term. CHAD: That's a good lesson [laughs]. One of the other things, you know, while you were a host of Giant Robots, you were the first host. I remember, you know, encouraging you to be the first host, and I think we talked about that in one of the episodes along the way. But we also transitioned the format a little bit, especially as you started to work on products here; you know, it was more about the building of those products and following along with those. And one of the things that sort of half-jokingly defined, I think, your impact on a lot of products was pricing, experimenting with pricing, learning about pricing, increasing prices more than people were maybe comfortable doing so. How has that worked out with Tuple, pricing in particular? BEN: It's really hard to say. It's hard to know what, like, the other path would have been through the world-. We sort of decided from, like, the early days that we wanted to have, like, a fairly premium price. Like, we wanted to be the product that was really good and was, like, a little bit annoyingly expensive, but you still paid for it because it felt worth it. And I think people could debate in both directions whether we nailed that or not. We have had a price increase that we ended up rolling back. We went, like, a little too far one time and said, "You know what? I think we're a little bit over," and we reverted that. But I would say even today, we are still a fairly pricey product. I mean, I'm pretty happy with how the company has done. I can't prove to you that, like, if the price were half what it is, we would have, you know, better success or not. CHAD: I think it'd be very hard to make the argument that if it was half that, you would have double the number of customers. BEN: Yeah, that's probably not true. CHAD: Not with the customers that you have, who are companies that will pay for products that they use as much as Tuple. BEN: Yeah, I'm happy serving the kind of companies, and they end up being mostly tech companies that really value developer happiness. When their developers come to them and they say, "We don't want to pair over Zoom. We like this thing. It's better. It feels nicer to use," they say, "Okay," and they buy the tool for them. There are places where that's not the case. And they say, "We already have a thing that does screen sharing. You're not allowed to buy this." We don't invest a lot of time trying to sell to those people or convince them that they're wrong. And I'm pretty happy serving sort of the first group. CHAD: So, you've mentioned that you've still been podcasting. To be honest, I didn't realize you were starting something new. Is it live now? BEN: It is live now, yeah. CHAD: Awesome. Where can people find that? BEN: hackersincorporated.com. It's about the transition from developer to founder, which is kind of what we've been touching on here. Yeah, hopefully, the audience is developers who want to start something or have started something who are maybe a little bit further behind progression-wise. And it's kind of, like, I have some lessons, and Adam has some lessons, and, you know, we don't think that we're experts. But sometimes it's useful to just hear, like, two people's story and sort of see, like, what seemingly has worked for them. So, we've been trying to share things there. And I think people will find it useful. VICTORIA: I was going to ask you for a lesson, maybe give us a little sample about how would you advise someone who's built a product and wants to market it, and it's targeted towards developers since you mentioned that previously as well. BEN: Yeah, in a way, the question already contains a problem. It's like, oh, I built the product; now how do I market it? It's a little bit indicative of a very common failure mode for developers, which is that. They sort of assume, okay, after you make the product, you then figure out how you're going to market it. And marketing is sort of a thing you layer on later on when you realize that just, like, throwing it on Twitter or Product Hunt didn't really work. When we started building Tuple, I was out there marketing it already. So, I had two co-founders, so this is a luxury I had. My two co-founders were writing code, and I was out doing stuff. I was recording podcasts. I was tweeting about things. I was making videos. I was giving conference talks. And I was getting people to hear about our product well before it was done. In fact, I was even selling it. I was taking pre-orders for annual subscriptions to the app while it was still vaporware. So, I would say, like, you basically can't start marketing too early. If you start marketing early and no one really cares, well, then you don't really have to build it probably. I would actually even go a little further and say, like, I started marketing Tuple before we had a product available. But in reality, I started marketing Tuple seven or so years before that when I started publishing things through thoughtbot. It's like when I was traveling around giving talks about Ruby, and when I was making screencasts about Vim, and when I was running Upcase, I was, over time, building an audience. And that audience was useful for thoughtbot, and it also was useful for me so that when I left, I had something like 10,000 Twitter followers or something, a few thousand people on our mailing list. But there were a lot of developers that already sort of knew me and trusted me to make fairly good things. And so, when I said, "Hey, I've made a new thing, and it's for you," I really benefited from those years of making useful content and trying to be useful on the internet. And in the early days, we had people sign up, and they would say, "I don't even really think I'm going to use this. But I've learned so much from you over the years that I want to support you, so I'm going to pay for a subscription." VICTORIA: I like your answer because I think the same thing when people ask me, like, because I am an organizer for Women Who Code, and I know all these great people from showing up for years in person months over months. And so, then people will ask, "Oh, how do I recruit more women in my company?" I'm like, "Well, you got to start showing up [laughs] now and do that for a couple of years, and then maybe people will trust you," right? So, I really like that answer. WILL: How has your relationship with Chad continued to grow since you left? Because seven years at the company is a lot. And it seems like you're still on really, really good terms, and you're still friends. And I know that doesn't happen at every company. BEN: I mean, it was tough deciding to leave. I think, like, both of us felt pretty sad about it. That was the longest I'd ever worked anywhere, and I really enjoyed the experience. So, I think it was tough on both sides, honestly. But we haven't kept in that much touch since then. I think we've emailed a handful of times here and there. We're both sociable people, and we sort of get each other. And there's a long history there. So, I think it's just easy for us to kind of drop back into a friendly vibe is sort of how I feel about it. CHAD: Yeah. And the way I explain it to people, you know, when you're leading a company, which Ben and I both are, you put a lot of energy into that and to the people who are on that team. If you're doing things right, there's not really hard feelings when someone leaves. But you need to put in a lot of effort to keep in touch with people outside of the company and a lot of energy. And, to be honest, I don't necessarily do as good a job with that as I would like because it's a little bit higher priority to maintain relationships with them, the people who are still at thoughtbot and who are joining. BEN: What you're saying is I'm dead to you [laughter]. That's CEO, for you're dead to me. CHAD: No. It's just...no hard feelings. BEN: Totally. CHAD: I think one of the things that has been great about the show over the years is that we haven't been afraid to change the format, which I think has been important to keeping it going. So, there is sort of; in fact, the website now is organized into seasons. And I went back and re-categorized all the episodes into seasons. And when the seasons were made up of, like, sort of the format of the show or particular hosts...when we started, it was just an interview show, and it was largely technical topics. And then we started The Bike Shed, and the technical topics sort of moved over there. But it also went with your interests more under the product and business side. Then you started working on products at thoughtbot, so it started to go even more in that. And I think Chris joined you on the show, and that was sort of all about those topics. BEN: Yeah, that makes sense. I think if you don't let the hosts kind of follow their interests, they're going to probably burn out on the thing. It's not fun to force yourself, I think, to record a podcast. CHAD: Yeah. And then when you left, you know, I took over hosting and hosted by myself for a while, went back to the interview format, but then was joined by Lindsey for a little while. We experimented with a few different things: one, interviews, but then we did a whole, just under a year, where we followed along with three companies. And each month, we would have an interview episode where we talked to them, all three companies, about the same topic. And then, we also did an episode with just Lindsey and I talking about that topic and about what we learned from the startup companies that we were following along with for the year. And now we're back to interview freeform, different guests, different topics. It seems like we're going to stick with that for a little while. But, obviously, as Will and Victoria have said, like, we'll probably change it again in some way, you know, a year, two years, three years from now. VICTORIA: Yeah, and I'm definitely bringing my interest around DevOps and platform engineering, so you'll see more guests who have that focus in their background. And with that, sometimes my interview style is more; how do I ask a question that I can't read from your developer docs and that I might not understand the answer to? [laughs] That's kind of where I like to go with it. So yeah, I'm really excited about...it's probably one of my favorite parts of my job here at thoughtbot because I get to meet so many interesting people. And, hopefully, that's interesting to everyone else [laughs] and our guests, yeah. BEN: Totally. Well, I dramatically underestimated how awesome it would be to meet all kinds of cool people in the industry when I started the podcast. I didn't truly connect in my head, like, wait a second, if I have a 45-minute conversation with, like, a lot of prominent, awesome people in our field, that's going to be really interesting and useful for me. So, I think, yeah, it's nice to be in the hosting seat. VICTORIA: And it's so surprising how I'll meet someone at a conference, and I'll invite them onto the podcast. And the way it winds up is that whatever we're talking about on the show is directly relevant to what I'm working on or a problem that I have. It's been incredible. And I really appreciate you for coming back for our 500th Episode here. CHAD: Ben, thanks very much again for joining us, and congratulations on all the success with Tuple. And I wish you the best. BEN: Thank you so much. Thanks for being a continuing customer. I really appreciate it. CHAD: Next, we caught up with Chris Toomey, who had a run as co-host of the show with Ben throughout 2016. CHRIS: Hi there. Thanks for having me. So, we're talking with all of the past hosts. I know you joined the show, and you were on it with Ben. And then you moved over to The Bike Shed, right? CHRIS: Yeah. So, I had co-hosted with Ben for about six months. And then I think I was transitioning off of Upcase, and so that ended sort of the Giant Robots “let's talk about business” podcast tour for me. And then, I went back to consulting for a while. And, at some point, after Derek Prior had left, I took over as the host of The Bike Shed. So, I think there was probably, like, a year and a half, two-year gap in between the various hostings. CHAD: Are you doing any podcasting now? CHRIS: I'm not, and I miss it. It was a lot of fun. It was, I think, an ideal medium for me. I'm not as good at writing. I tend to over-edit and overthink. But when you get me on a podcast, I just start to say what's in my head, and I tend to not hate it after the fact. So [chuckles], that combination I found to be somewhat perfect for me. But yeah, lacking that in my current day-to-day. CHAD: Well, what's been taking up your time since you left? CHRIS: I had decided it was time to sort of go exploring, try and maybe join a startup, that sort of thing. I was sort of called in that direction. So, just after I left thoughtbot, I did a little bit of freelancing, but that was mostly to sort of keep the lights on and start to connect with folks and see if there might be an opportunity out there. I was able to connect with a former thoughtbot client, Sam Zimmerman, who was looking to start something as well. And so, we put our act together and formed a company called Sagewell, which was trying to build a digital financial platform for seniors, which is a whole bunch of different complicated things to try and string together. So, that was a wonderful experience. I was CTO of that organization. And I think that ran for about two and a half years. Unfortunately, Sagewell couldn't quite find the right sort of sticking point and, unfortunately, shut down a little bit earlier in this year. But that was, I would say, the lion's share of what I have done since leaving thoughtbot, really wonderful experience, got to learn a ton about all of the different aspects of building a startup. And I think somewhat pointedly learned that, like, it's messy, but I think I do like this startup world. So, since leaving Sagewell, I've now joined a company called August Health, which has a couple of ex-thoughtboters there as well. And August is post their Series A. They're a little bit further along in their journey. So, it was sort of a nice continuation of the startup experience, getting to see a company a little bit further on but still with lots of the good type of problems, lots of code to write, lots of product to build. So, excited to be joining them. And yeah, that's mostly what's taking up my time these days. CHAD: So, I know at Sagewell, you made a lot of technical architecture, team decisions. It was Rails in the backend, Svelte in the frontend, if I'm not mistaken. CHRIS: Yep, that's correct. CHAD: You know, hindsight is always 2020. Is there anything you learned along the way, or given how things ended up, that you would do differently? CHRIS: Sure. I was really happy with the tech stack that we were able to put together. Svelte was probably the most out there of the choices, I would say, but even that, it was sort of relegated to the frontend. And so, it was a little bit novel for folks coming into the codebase. Most folks had worked in React before but didn't know Svelte. They were able to pick it up pretty quickly. But Inertia.js was actually the core sort of architecture of the app, sort of connected the frontend and the backend, and really allowed us to move incredibly quickly. And I was very, very happy with that decision. We even ended up building our mobile applications, both for iOS and Android. So, we had native apps in both of the stores, but the apps were basically wrappers around the Rails application with a technology similar to Turbolinks native–if folks are familiar with that so, sort of a WebView layer but with some native interactions where you want. And so, like, we introduced a native login screen on both platforms so that we could do biometric login and that sort of thing. But at the end of the day, most of the screens in the app didn't need to be differentiated between a truly native mobile app and what like, mobile WebView would look like. So, we leaned into that. And it was incredible just how much we were able to do with that stack and how quickly we were able to move, and also how confidently we were able to move, which was really a nice thing. Having the deep integration between the backend and the frontend really allowed a very small team to get a lot done in a short time. CHAD: Does that code live on in any capacity? CHRIS: No. CHAD: Oh. How does that make you feel? [chuckles] CHRIS: It makes me feel very sad, I will say. That said, I mean, at the end of the day, code is in service of a business. And so, like, the code...there are, I think, probably a couple of things that we might be able to extract and share. There were some interesting...we did some weird stuff with the serializers and some, like, TypeScript type generation on the frontend that was somewhat novel. But at the end of the day, you know, code is in service of a business, and, unfortunately, the business is not continuing on. So, the code in the abstract is...it's more, you know, the journey that we had along the way and the friends we made and whatnot. But I think, for me, sort of the learnings of I really appreciate this architecture and will absolutely bring it to any new projects that I'm building from, you know, greenfield moving forward. VICTORIA: I'm curious what it was like to go from being a consultant to being a big player in a startup and being responsible for the business and the technology. How did that feel for you? CHRIS: I would say somewhat natural. I think the consulting experience really lent well to trying to think about not just the technical ramifications but, you know, what's the business impact? How do we structure a backlog and communicate about what features we want to build in what order? How do we, you know, scope a minimal MVP? All those sorts of things were, I think, really useful in allowing me to sort of help shape the direction of the company and be as productive of an engineering team as we could be. CHAD: A lot of the projects you worked on at thoughtbot were if not for startups, helping to launch new products. And then, a lot of the work you did at thoughtbot, too, was on Upcase, which was very much building a business. CHRIS: Yes. I definitely find myself drawn in that direction, and part of like, as I mentioned, I seem to be inclined towards this startup world. And I think it's that, like, the intersection between tech and business is sort of my sweet spot. I work with a lot of developers who are really interested in getting sort of deeper into the technical layers, or Docker and Kubernetes and orchestration. And I always find myself a little bit resistant to those. I'm like, I mean, whatever. Let's just...let's get something out there so that we can get users on it. And I am so drawn to that side, you know, you need both types of developers critically. I definitely find myself drawn to that business side a little bit more than many of the folks that I work with, and helping to bridge that gap and communicate about requirements and all those sort of things. So, definitely, the experience as a consultant really informed that and helped me have sort of a vocabulary and a comfort in those sort of conversations. WILL: How did Upcase come about? Because I know I've talked to numerous people who have gone through Upcase. I actually went through it, and I learned a ton. So, how did that come about? CHRIS: I think that was a dream in Ben Orenstein's eye. It started as thoughtbot Learn many, many years ago. There was a handful of workshops that had been recorded. And so, there were the video recordings of those workshops that thoughtbot used to provide in person. Ben collected those together and made them sort of an offering on the internet. I think Chad, you, and I were on some podcast episode where you sort of talked about the pricing models over time and how that went from, like, a high dollar one-time download to, like, $99 a month to $29 a month, and now Upcase is free. And so, it sort of went on this long journey. But it was an interesting exploration of building a content business of sort of really leaning into the thoughtbot ideal of sharing as much information as possible, and took a couple of different shapes over time. There was the weekly iterations of the video series that would come out each week, as well as the, like, longer format trails, and eventually some exercises and whatnot, but very much an organic sort of evolving thing that started as just a handful of videos and then became much more of a complete platform. I think I hit the high points there. But, Chad, does that all sound accurate to you? CHAD: Yeah, I led the transition from our workshops to Learn, which brought everything together. And then, I stepped away as product manager, and Ben took it the next step to Upcase and really productized it into a SaaS sort of monthly recurring billing model and took it over from there. But it still exists, and a lot of the stuff there is still really good [laughs]. CHRIS: Yeah, I remain deeply proud of lots of the videos on that platform. And I'm very glad that they are still out there, and I can point folks at them. VICTORIA: I love that idea that you said about trying to get as much content out there as possible or, like, really overcommunicate. I'm curious if that's also stayed with you as you've moved on to startups, about just trying to get that influence over, like, what you're doing and how you're promoting your work continues. CHRIS: I will say one of the experiences that really sticks with me is I had followed thoughtbot for a while before I actually joined. So, I was reading the blog, and I was listening to the podcasts and was really informing a lot of how I thought about building software. And I was so excited when I joined thoughtbot to, like, finally see behind the curtain and see, like, okay, so, what are the insider secrets? And I was equal parts let down...actually, not equal parts. I was a little bit let down but then also sort of invigorated to see, like, no, no, it's all out there. It's like, the blog and the open-source repos and those sort of...that really is the documentation of how thoughtbot thinks about and builds software. So, that was really foundational for me. But at the same time, I also saw sort of the complexity of it and how much effort goes into it, you know, investment time Fridays, and those sort of things. Like, a thoughtbot blog post is not a trivial thing to put up into the world. So many different people were collaborating and working on it. And so, I've simultaneously loved the sharing, and where sharing makes sense, I've tried to do that. But I also recognize the deep cost. And I think for thoughtbot, it's always made sense because it's been such a great mechanism for getting the thoughtbot name out there and for getting clients and for hiring developers. At startups, it becomes a really interesting trade-off of, should we be allocating time to building up sort of a brand in the name and getting ourselves, you know, getting information out there? Versus, should we be just focusing on the work at hand? And most organizations that I've worked with have bias towards certainly less sharing than thoughtbot, but just not much at all. Often, I'll see folks like, "Hey, maybe we should start a blog." And I'm like, "Okay, let's just talk about how much effort that [laughs] actually looks like." And I wonder if I'm actually overcorrected on that, having seen, you know, the high bar that thoughtbot set. CHAD: I think it's a struggle. This is one of my [laughs] hot topics or spiels that I can go on. You know, in most other companies, that kind of thing only helps...it only helps in hiring or the people being fulfilled in the work. But at most companies, your product is not about that; that's not what your business is. So, having a more fulfilled engineering team who is easier to hire—don't get me wrong, there are advantages to that—but it doesn't also help with your sales. CHRIS: Yes. CHAD: And at thoughtbot, our business is totally aligned with the people and what we do as designers and developers. And so, when we improve one, we improve the other, and that's why we can make it work. That is marketing for the product that we actually sell, and that's not the case at a SaaS software company. CHRIS: Yes, yeah, definitely. That resonates strongly. I will say, though, on the hiring side, hiring at thoughtbot was always...there was...I won't say a cheat code, but just if someone were to come into the hiring process and they're like, "Oh yeah, I've read the blog. I listen to the podcast," this and that, immediately, you were able to skip so much further into the conversation and be like, "Okay, what do you agree with? What do you disagree with? Like, let's talk." But there's so much. Because thoughtbot put so much out there, it was easy to say, like, "Hey, this is who we are. Do you like that? Is that your vibe?" Whereas most engineering organizations don't have that. And so, you have to try and, like, build that in the context of, you know, a couple of hour conversations in an interview, and it's just so much harder to do. So, again, I've leaned in the direction of not going anywhere near thoughtbot's level of sharing. But the downside when you are hiring, you're like, oh, this is going to be trickier. CHAD: Yeah. One of the moments that stands out in my mind, and maybe I've told this story before on the podcast, but I'll tell it again. When we opened the New York studio, it was really fast growing and was doing a lot of hiring. And one of the people who had just joined the company a couple of weeks before was doing an interview and rejected the person was able to write an articulate reason why. But it all boiled down to this person is, you know, not a fit for thoughtbot. Based on what they were able to describe, I felt very confident with the ability or with the fact that they were able to make that call, even though they had been here only a couple of weeks, because they joined knowing who we were, and what we stand for, and what our culture and our values are, and the way that we do things, and all that kind of thing. And so, yeah, that's definitely a huge benefit to us. VICTORIA: I've certainly enjoyed that as well, as someone who hires developers here and also in meeting new companies and organizations when they already know thoughtbot. That's really nice to have that reputation there, coming from my background—some really more scrappier startup kind of consulting agencies. But, you know, I wanted to talk a little bit more about your podcasting experience while you're here. So, I know you were on both The Bike Shed and Giant Robots. Which is the better podcast? [laughter] So, what's your...do you have, like, a favorite episode or favorite moment, or maybe, like, a little anecdote you can share from hosting? CHRIS: Well, I guess there's, like, three different eras for me in the podcasting. So, there's Giant Robots with Ben talking more about business stuff, and I think that was really useful. I think it was more of a forcing function on me because I sort of...Both Ben and I were coming on; we were giving honest, transparent summaries of our, like, MRR and stats and how things were growing, and acted as sort of an accountability backstop, which was super useful but also just kind of nerve-wracking. Then, when I joined the Bike Shed, the interviewing sequence that I did each week was just a new person that I was chatting with. And I sort of had to ramp them up on, hey, here's a quick summary on how to think about podcasting. Don't worry, it'll be great. Everybody have fun. But I was finding each of the guests. I was sort of finding a topic to talk about with them. So, that ended up being a lot more work. And then, the last three years chatting with Steph that was by far my favorite. There was just such a natural back-and-forth. It really was just capturing the conversations of two developers at thoughtbot and the questions we would ask each other as we hit something complicated in a piece of code or, "Oh, I saw this, you know, article about a new open-source repository. What do you think about that?" It was so much easier, so much more natural, and, frankly, a lot of fun to do that. And, two, I actually do have an answer to the favorite podcast episode, which is the first episode that Steph was ever on. It was before she actually joined as a co-host. But it was called “What I Believe About Software.” And it was just this really great, deep conversation about how we think about software. And a lot of it is very much, like, thoughtbot ideals, I would say. But yeah, Steph came in and just brought the heat in that first episode, and I remember just how enjoyable that experience was. And I was like, all right, let's see if I can get her to hang out a little bit more, and, thankfully, she was happy to join. WILL: What was your favorite position, I guess you can call it? Because you say you like the mixture of business and, you know, development. So, you've been in leadership as development director, CTO. You've been a web developer. You've been over content, like, with Upcase. What was your favorite position [inaudible 16:43] you were doing, and why was it your favorite? CHRIS: The development director role feels like sort of a cheating answer, but I think that would be my answer because it contained a handful of things within it. Like, as development director, I was still working on client projects three days a week. And then, one day a week was sort of allocated to the manager-type tasks, or having one-on-ones with my team sort of helping to think about strategy and whatnot. And then, ideally, still getting some amount of investment time, although the relative amounts of those always flexed a little bit. Because that one sort of encompassed different facets, I think that's going to be my answer. And I think, like, some of what drew me to consulting in the first place and kept me in that line of work for seven years was the variety, you know, different clients, as well as, even within thoughtbot, different modes of working in podcasts or video. Or there was a bootcamp that I taught, a session of Metis, which that was a whole other experience. And so, getting that variety was really interesting. And I think as sort of a tricky answer to your question, the development director role as a singular thing contained a multitude, and so I think that was the one that would stand out to me. It's also the most, you know, the one that I ended on, so [laughs] it might just be recency bias, but yeah. VICTORIA: Oh, I love that. Is there anything else that you would like to promote on the podcast today? CHRIS: No, although as you ask the question, I feel like I should, I don't know, make some things to promote, get back into some, I don't know, content generation or something like that. But for now, no. I'm, you know, diving into the startup life, and it's a wonderful and engrossing way to do work, but it does definitely take up a lot of my headspace. So, it's an interesting trade-off. But right now, I don't know; if folks are online and they want to say hi, most of my contact information is readily available. So, I would love to say hi to folks, anyone that listened in the past or, you know, has any thoughts in the now. Would love to connect with folks. But otherwise, yeah, thank you so much for having me on. CHAD: In 2017, I took over from Ben as solo host of the show but was joined by Lindsey Christainson as cohost in 2019. After some time away from thoughtbot, Lindsey is back with us and we sat down to catch up with her. VICTORIA: Why don't you tell me about your current role with thoughtbot? LINDSEY: I am currently supporting marketing and business development at thoughtbot, as well as working as a marketing consultant for thoughtbot clients. VICTORIA: Great. And I understand that you had worked with thoughtbot many years ago, and that's when you also came on as a co-host of Giant Robots. Is that right? LINDSEY: Yeah, a couple of years ago. I left thoughtbot in spring of 2021. And I forget how long my stint was as a co-host of Giant Robots, but over a year, maybe a year and a half, two years? CHAD: Yeah, I think that's right. I think you started in 2019. LINDSEY: Yeah. Yeah, that sounds right. And Chad and I were co-hosts, I think, similar to the setup today in which sometimes we hosted together, and sometimes we were conducting interviews separately. CHAD: And then we sort of introduced a second season, where we followed along with a batch of companies over the course of the entire season. And that was fun, and we learned a lot. And it was nice to have consistent guests. LINDSEY: Yeah, that was a lot of fun. I really liked that format. I don't know; they almost were, like, more than guests at that point. They were just like other co-hosts [laughs] that we could rely on week in, week out to check in with them as they're working on early-stage companies. So, every time we checked in with them, they usually had some new, exciting developments. WILL: I really like that idea. How did y'all come up with that? CHAD: I'm not sure. I think a few years before I had taken over hosting of the show, and I forget...my memory maybe is that I went to Lindsey and said, "You know, let's do something different." But I'm not sure. Does that match your memory, Lindsey? LINDSEY: Yeah, I think there were two main drivers; one was I think you were feeling like you were having similar conversations in the interviews every time. Like, you couldn't get to a certain depth because every time you were interviewing someone, you were doing, like, the, "Well, tell me your founding story." And, you know, how did you raise funding? It kind of got a little bit repetitive. And then, on the side, the few we had done together, I think we both really enjoyed. So, we were thinking, like, what's the format in which the two of us could co-host together more regularly? Because I'm a pleasure to talk to [laughter]. I think you were like, I need to talk to Lindsey more. [inaudible 3:13] VICTORIA: What is your hosting style? How would you describe your approach to hosting a podcast? LINDSEY: I mean, obviously, it's a podcast about products and business. I think as a marketer, I am, you know, drawn a lot to the marketing side, so tending to ask questions around go-to-market audience, users. That's always just, like, a particular interest of mine. But then also, like, the feelings. I love asking about the feelings of things, you know, how did it feel when you started? How did it feel when you made this tough decision? So, that's another thing I think I noticed in my interviews is asking about some of the emotions behind business decisions. VICTORIA: And I like hearing about how people felt at the time and then how they felt afterwards [laughs]. And, like, how people around them supported each other and that type of thing. That's really fun. I'm curious, too, from your marketing background and having to do with podcasts like; some founders, I think, get the advice to just start a podcast to start building a community. But I'm curious on your thoughts about, like, how does podcasting really play into, like, business and marketing development for products? LINDSEY: Oh yeah. It's become definitely, like, a standard channel in B2B these days. I feel like that it's pretty typical for a company to have a podcast as one way that they engage their audience and their users. In marketing, you're really vying for people's attention, and people's attention span is getting shorter and shorter. So, like, if you have an ad or a blog, you're getting, like, seconds, maybe minutes of someone's attention. And whereas something like a podcast offers a unique channel to have someone's undivided attention for, you know, 30 minutes, an hour, and if you're lucky, you know, checking back in week over week. So, it became a really popular method. That said, I think you're probably also seeing the market get saturated [laughs] with podcasts now, so some diminishing returns. And, you know, as always, kind of looking for, you know, what's the next way? What's the next thing that people are interested in in ways to capture their attention? CHAD: What is the next thing? LINDSEY: I don't know, back to micro-content? TikTok videos -- CHAD: Yeah, I was going to say TikTok, yeah. LINDSEY: Yeah, you know, 10-30 seconds, what can you communicate? VICTORIA: I see people live streaming on Twitch a lot for coding and developer products. LINDSEY: Yeah, I think we've seen some of that, too. We've been experimenting more at thoughtbot with live streaming as well. It's another interesting mechanism. But yeah, I don't know, it's interesting. It's another form of, like, community and how people engage with their communities. So, it's always evolving. It's always evolving, and sometimes it's not. Sometimes, people just do want to get in a room together, too, which is always interesting. WILL: What has been, in your experience, the good the bad? Like, how do you feel about the way that it has shifted? Because I think you started in, like, 2000, like, kind of earlier 2000, 2005, something around there. And it was totally different than now like you're saying. Because I feel like, you know, Channel 5 30-second ad, you know, with some of the marketing depending on what you're doing, to now to where you're, like, you're paying influencers to advertise your product, or you're doing an ad. Or it's more social media-driven and tech-driven. What has been your opinion and feelings on the way that it has grown and evolved? LINDSEY: Marketing, in general, yeah, I graduated college in 2005 and started my marketing career. And yeah, you could, like, actually get people to click on banner ads back then, which was pretty [inaudible 07:14] [laughs]. WILL: I forgot about banner ads [laughs]. LINDSEY: I don't know, yeah. I don't know. In order for myself to not just get too frustrated, I think I've got to, like, view it as a game kind of. What new things are we going to try? You know, what do we see work? But it can really depend. And I've always been in B2B side of things. And consumer, I'm sure, has its own kind of evolution around how people engage and how they consume content and byproducts. But in B2B, you know, it can really depend on industry too. You know, I'm working with a client right now in the senior living space, and they're really big in in-person conferences. So, that's how people consume, get a lot of their information and, make connections, and learn about new products. So, it's been interesting to work in an industry that what might be considered, like, a little bit more old-school channels are still effective. And then just thinking about how you weave in the new channels with the existing ones without ignoring them. They might get information in conferences, but they're still a modern human who will then, you know, search online to learn more, for example. VICTORIA: It reminds me of a phrase I like to say, which is that, like, technology never dies; you just have more of it. There's just more different options and more different ways to do things. And some people are always, you know, sometimes you have to be flexible and do everything. CHAD: So, tell us more about what you did in between...after you left thoughtbot, what did you do? LINDSEY: I was heading up B2B marketing for a company called Flywire, which is headquartered in Boston but is a global company now. And they were just kind of starting their B2B business unit, which, as I mentioned, B2B is my personal specialty. I had been connected to their CMO through the Boston startup community. And yeah, I was helping them kind of launch their go-to-market for B2B. The industries they were in before...they got their start in higher education and then expanded in healthcare and found a niche in luxury travel, and then we were figuring out the B2B piece. But yeah, I was there for about a year and a half. They actually went public the second week I was there, which was an interesting [laughs] experience. I knew they were, like, on that journey, but it was kind of funny to be there the second week, and people were, like, "Congrats." And I was like, "Well, I definitely didn't have anything to do with it because I just finished my onboarding, but thank you," [laughs]. CHAD: One of the things that really impressed me when you joined thoughtbot was the way in which you learned about who we were and really internalized that in a way where you were then able to pretty meaningfully understand our market, our positioning in the market, and come up with new strategies for us. I assume that's something you're good at in general [laughs]. How do you approach it? How did you approach it when you joined Flywire, for example? And how was it the same or different than how you approached thoughtbot? LINDSEY: Ooh, yeah, that's a good question. And I appreciate that comment because it's difficult. But I think, yeah, with any new organization that I'm joining, you know, I think starting out with your kind of mini-listening tour of your key stakeholders across, you know, the different departmental focuses to get a sense of, what are the challenges? What are the opportunities? It's actually like, you know, it's the SWOT analysis, kind of trying to fill in your own mind map of a SWOT analysis of where the company is. What are the major hurdles you're facing? Where are people trying to go? What have they tried that's worked? What have they tried that's failed? But then, like, I think for the culture component, I think a part of that maybe is, like, feel, and maybe something that I do have a knack for. Again, maybe this is, like, you know, emotional intelligence quotient, where it's like, you know, but it's the company, you know, who is this company? What is important to them? How do they work and go about things? I know thoughtbot is certainly very unique, I think, in that arena in terms of being, like, a really value-driven company, and one where especially, like, marketing and business work is, like, distributed across teams in a really interesting way. You know, I'm sure the fact that it fascinated me and was something I could get passionate and get behind was something that also helped me understand it quickly. CHAD: I was excited that...or it was sort of a coincidence because I had reached out to you and without realizing that you had left Flywire. And Kelly, who had been doing a combined sales and marketing role, was going on parental leave. And so, it was fortuitous [laughs] that you were able to come back and help us and provide coverage, like, Kelly was out. LINDSEY: Yeah, it definitely felt like stars aligned moment, which, you know, I'm pretty woo-woo, so I believe in [laughter]...I believe in that kind of thing. You know, yeah, it was wild. It really did feel like your email came out of nowhere. And, you know, I mentioned it, obviously, to my partner and my friends. And they were like, "Oh, he definitely knows, like, that you left your last company." And I'm like, "I actually don't think he does [laughter]. I actually don't think he does." Yeah, and then we started chatting about me coming back to help. And it was great. thoughtbot makes it hard to work anywhere else [laughs]. So, I was happy to come back. I missed the team. CHAD: And one of the exciting things, and you've mentioned it, is you're not just doing marketing for thoughtbot now. We have started to offer your services to our clients. LINDSEY: Yeah, I'm super excited about this. And it's something I'd started thinking about. I had decided to take some time off between Flywire and my next thing and had started thinking about doing marketing, consulting. And as I'm doing that, I'm thinking a lot about how thoughtbot does consulting and, you know, wanting to emulate something like that. So, I started back up at thoughtbot. That wasn't part of the plan. I was just going to, you know, fill in for Kelly and help with marketing things. But then, you know, a good opportunity arose to work on a client, and I was really excited. When, you know, Chad, you and I chatted through it, we came to the conclusion that this was something worth exploring under the, you know, thoughtbot umbrella. And it's been a really great experience so far. And we now have brought on another client now. And if you're listening and need early-stage B2B marketing support, reach out to lindsey@thoughtbot.com. CHAD: Definitely. And Lindsey is pretty good, so you're going to like it [laughs]. LINDSEY: Yeah, you're going to like the way you look. WILL: Yeah, definitely. Because I can even feel your presence here, you know, coming back. Because even like, you know, the market where it's at now and some of the suggestions that, you know, you've been helping us. For example, like, I do a lot of React Native, and you're like, "Hey, you know, blog posts have done a lot of traction, you know, let's get some more blog posts out in the market to help with the traffic and everything." So, the question I have with that is, like, thank you for even suggesting that because it's, like, those little things that you don't even think about. It's like, oh yeah, blog posts, that's an easy transition to help the market, clients, things like that. But with the market the way it is, what has been your experience working during this time with the market? I don't know if you want to call it struggling, but whatever you want to call it that, it's doing [laughs]. LINDSEY: Yeah, I mean, the economy is difficult now. We also went through a really tough spot when I was here last time. During COVID, you know, we faced a major company challenge. And, I mean, I'll let Chad speak to it, but I would imagine it's probably one of the bigger, like, economic inflection points that you faced. Would you say that? CHAD: Yeah, definitely. The thing about it that made it worse was how quickly it happened. You know, it was something that you didn't see coming, and then, you know, about 40% of our business went away in a single month. That's the kind of thing that was a real shock to the system. I think the thing that made it difficult, too, was then the aspects of COVID, where we were no longer able to go into our studios. We were all working remotely. We were isolated from each other. And so, that made executing on what needed to be done in order to make the company survive additionally challenging. LINDSEY: Yeah, so I think, like, going through that experience, also, and seeing how the team and the leadership team rallied together to get through it. And then, you know, ultimately, I think 2021 and 2022 have, like, really good years. That was a really positive experience. And something I'll definitely take with me for a while is just, like, keeping a cool head and just knowing you have, like, really smart, talented folks with you working on it and that you can get through it. And just, like, doing some, I mean, we relied on what we did best, which was, like, design thinking, using design exercise to think about, like, how we might re-organize the company, or what other services we might try launching, or how might we re-package, you know, larger services into smaller more palatable services when people have, like, kind of tighter purse strings. So, that was, like, a great educational experience, and I think something we just continue to do now: be open to change, be open to changing how we package services, what clients we go after, and coming at it with, like, an agile, experimental mindset and try to find out what works. VICTORIA: I really appreciate that. And it aligns now with the new service we've developed around you and the marketing that you provide. And I'm curious because I've had founders come up to me who say they need help with marketing or they need to, like, figure out their marketing plans. So, say you've met a founder who has this question, like, what questions do you ask them to kind of narrow down what it is they really need and really want to get out of a marketing plan? LINDSEY: I've been thinking about this a lot recently. And, like, obviously, I see other marketing leaders in the market. Marketers like to talk about what they do on LinkedIn [laughs], so I get to...I read a lot about different people's approaches to this. And some people kind of go in and are like, okay, this is what you need. This is how we're going to do it, and they start executing on it. And I really do take a very collaborative approach with founders. I think they're, especially in early stage, they're your most important asset in a way, and a lot of their intuition around the market and the business, you know, it's gotten them to where they're at. And so, I think starting from the point of, like, taking what they view as priorities or challenges, and then helping them better explore them or understand them with my own marketing experience and expertise, to

Welcome to Remote Ruby and thanks for joining us!  It's Jason and Andrew today and do they have so much to talk about. RailsConf 2023 is coming up, Andrew booked his flight and lodging early, Jason announces he's doing a podcast with Brittany while they're there, and the guys discuss how their ADHD is so different from each other.  Then they discuss npx, the benefits of using it, and how it can be useful in Ruby.  Jason and Andrew talk about building user interfaces in Ruby, creating games with DragonRuby, learning Rust and Python for hardware projects, and using OpenAI API for Ai projects. We'll also hear about their programming backgrounds, not liking math, regrets about not taking a statistics class seriously, and experiences with other college classes. Press download now to hear more!  [00:04:19] The guys are excited to go to RailsConf but Jason's feeling socially anxious since he had surgery. [00:06:03] Andrew explains what Hashnode is since Jason has no idea what it is.[00:06:28] In the wonderful world of Ruby, Andrew's been scripting lately since he wanted to have fun, and if you don't know what npx is, he explains what it is. Jason and Andrew also discuss using npx with Tailwind and esbuild, [00:11:09] Jason brings up using standards VS Code extension and mentions how surprisingly fast it is.[00:13:35] Jason mentions Nick Schwaderer taking on building a new Shoes project, which was a GUI graphic user interface library for Ruby, built by, why the lucky stiff. It looks like their using WebView, and if anyone can explain it, please Tweet Andrew on Twitter or message him on discord. [00:15:17] The guys talk about building user interfaces in Ruby, creating games with DragonRuby, and a Tweet by Amir Rajan about DragonRuby.[00:20:35] Jason tells us about trying to learn Rust and Python for hardware projects, and Andrew tells us about a widget he built using Rubyist.[00:22:28] There's a discussion on using OpenAI API, Andrew has an interest in creating a profitable business with web3 technology and AI, Jason mentions “Ask Rails,” an Open AI powered chat to help you with all things Ruby on Rails.[00:25:42] The conversation shifts to Jason and Andrew's programming backgrounds and their interest in using Ruby for hardware projects. [00:29:34] Have you heard of PicoRuby? Also, if you know mRuby, please reach out to Jason or Andrew because they need to talk to you.[00:31:50] Andrew was asked to be a Guide at RailsConf, saw the email too late, and he's not doing it because of his commitment issues.[00:34:37] Jason and Andrew discuss their rabbit holes. One is about a speech professor, the other is being back on Khan Academy filling gaps in math knowledge, and regrets about not taking statistics class seriously and other classes.   Panelists:Jason CharnesAndrew MasonSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterRailsConf 2023HashnodeAmir Rajan TwitterDragonRubyAsk Railsnpx-GitHubSearls After Dark #1-ChatJPN (YouTube)ShoesRubyistOpenAI APIPicoRuby-GitHubRuby Radar TwitterRuby for All Podcast

Episode 6: In this episode of Critical Thinking - Bug Bounty Podcast we sit down with mobile hacking legend Joel Margolis and get the scoop on his approach to popping bugs on Android.Follow us on twitter at: @ctbbpodcastWe're new to this podcasting thing, so feel free to send us any feedback here: info@criticalthinkingpodcast.ioShoutout to YTCracker for the awesome intro music!------ Links ------Follow your hosts Rhynorater & Teknogeek on twitter:https://twitter.com/0xteknogeekhttps://twitter.com/rhynoraterJoel's HackerOne Android Hacking Introduction:https://t.ly/f87DAndroid Pixel Lock Screen Bypasshttps://t.ly/Q_qqExploiting Deeplink URLs:https://inesmartins.github.io/exploiting-deep-links-in-android-part1/index.htmlJoel's get_schemas tool:https://github.com/teknogeek/get_schemasExample AndroidManfest.xml we referenced:https://t.ly/mcN1https://t.ly/ErVVAndroid docs for intent filters:https://developer.android.com/guide/components/intents-filters.htmlAndroid docs for “setAllowContentaccess”:https://t.ly/hXOZAndroid docs for “setAllowFileAccess”:https://developer.android.com/reference/android/webkit/WebSettings#setAllowFileAccess(boolean)Add JavaScript Interface to Webview:https://developer.android.com/reference/android/webkit/WebView#addJavascriptInterface(java.lang.Object,%20java.lang.String)Joel's SSL Pinning Bypass:https://gist.github.com/teknogeek/4dc35fb3801bd7f13e5f0da5b784c725Google Chrome Docs for Intent URLs:https://developer.chrome.com/docs/multidevice/android/intents/#considerationsJoel's Bug Bounty Report:https://hackerone.com/reports/423467

Обсуждаем построение трейдингового Android приложения, где важно доставлять данные как можно быстрее. Интересный факт - все графики рисуются в WebView.

Daniel talks to Manton about his continuing work to transition MarsEdit away from legacy WebView, the difficulty of doing so, and the thrill of becoming a "tangential expert" in web development. They react to a small rift in the WordPress community involving Matt Mullenweg and Go Daddy, and compare thoughts on what obligations, if any, consumers of open source software have to the creators. The post Episode 519: It’s A Gift appeared first on Core Intuition.

Another toaster strudel debate?! Plus, the results are in for the most listened-to podcast in the RoR community! :: drum roll :: Steph has a "Dear Gerrit" message to share. Chris has a follow-up on mobile app strategy. The Bike Shed: 328: Terrible Simplicity (https://www.bikeshed.fm/328) When To Fetch: Remixing React Router - Ryan Florence (https://www.youtube.com/watch?v=95B8mnhzoCM) Virtual Event - Save Time & Money with Discovery Sprints (https://thoughtbot.com/events/save-time-money-with-discovery) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: thoughtbot's next virtual event "Save Time & Money with Discovery Sprints" is coming up on June 17th, from 2 - 3 PM Eastern. It's a discussion with team members from product management, design and development. From a developer perspective, topics will include how to plan a product's architecture, both the MVP and future version, how to lead a tech spikes into integrations and conduct a build vs buy reviews of third party providers. Head to thoughtbot.com/events to register, the event is June 17th 2 - 3 PM ET. Even if you can't make it, registering will get you on the list for the recording. CHRIS: We're the second-best. We're the second-best. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: I'm very happy to report that I picked up a treat from the store recently. So while I was in Boston and we were hanging out in person, we talked about Pop-Tarts because that always comes up as a debate, as it should. And then also Toaster Strudels came up, so I now have a package of Toaster Strudels, and those are legit. Pop-Tart or Toaster Strudel, I am team Toaster Strudel, which I know you're going to ask me about icing and if I put it on there, so go ahead. I'm going to pause. [laughs] CHRIS: It sounds like I don't even need to say anything. But yes, inquiring minds want to know. STEPH: I think that's also my very defensive response because yes, I put icing on my Toaster Strudel. CHRIS: How interesting. [laughs] STEPH: But it feels like a whole different class of pastry. So I'm very defensive about my stance on Pop-Tarts with no icing put Strudel with icing. CHRIS: A whole different class of pastry. Got it. Noted. Understood. So did you travel? Like, were these in your luggage that you flew back with? STEPH: [laughs] Oh no. They would be all gooey and melty. No, we bought them when we got back to North Carolina. Oh, that'd be a pro move; just pack little individual Strudels as your airplane snack. Ooh, I might start doing that now. That sounds like a great airplane snack. CHRIS: You got to be careful though if the icing, you know, if it's pressurized from ground level and then you get up there, and it explodes. And you gotta be careful. Or is it the reverse? It's lower pressure up in the plane. So it might explode. STEPH: [laughs] Either way, it might explode. CHRIS: Well, yeah. If you somehow buy a packet of icing that is sky icing that is at that pressure, and you bring it down, then...but if you take it up and down, I think it's fine. If you open it at the top, you might be in danger. If you open icing under the ocean, I think nothing's going to happen. So these are the ranges that we're playing with. STEPH: I will be very careful sky icing and probably pack two so that way I have a backup just in case. So if one explodes, we'll be like, all right, now I know what I'm working with and be more prepared for the next one. CHRIS: That's just smart. STEPH: I try to make smart travel decisions, Toaster Strudels on the go. Aside from travel treats and sky icing, I have some news regarding Planet Argon, who is a Ruby on Rails consultancy regarding their latest published this year's Ruby on Rails community survey results. And so they list a lot of fabulous different topics in there. And one of them includes a learning section that highlights most listened to podcasts in the Ruby on Rails community as well as blogs and some other resources. And Bike Shed is listed as the second most listened to podcast in the Ruby on Rails community, so whoo, golf clap. CHRIS: Fantastic. STEPH: And in addition to that, the thoughtbot blog got a really nice shout-out. So the thoughtbot blog is in the number two spot for the most visited blogs in the community. In the first spot is Ruby Weekly, which is like, you know, okay, that feels fair, that feels good. So it's really exciting for the thoughtbot blog because a lot of people work really hard on curating and creating that content. So that's wonderful that so many people are enjoying it. And then I should also highlight that for the podcast in first place is Remote Ruby, so congrats to Chris, Jason, and Andrew for grabbing that number one spot. And Brittany Martin, host of the Ruby on Rails Podcast, along with Brian Mariani, Jemma Issroff, and Nick Schwaderer, are in the number three spot. And some people say that Ruby is losing steam but look at all that content and all those highly ranked podcasts. I mean, we like Ruby so much we're spending time recording ourselves talking about it. So I say long live Ruby, long live Rails. CHRIS: Yes. Long live Ruby indeed. And yeah, it's definitely an honor to be on the list and to be amongst such other wonderful shows. Certainly big fans of the work of those other podcasts. We even did a joint adventure with them at one point, and that was a really wonderful experience, so yeah, honored to be on the list alongside them. And to have folks out there in the world listening to our tech talk and nonsense always nice to hear. STEPH: Yeah. You and I show up and say lots of silly things and technical things into the podcast. The true heroes are the ones that went and voted. So thank you to everybody who voted. That's greatly appreciated. It's really nice feedback. Because we get listener responses and questions, and those are wonderful because it lets us know that people are listening. But I have to say that having the survey results is also really nice. It lets us know people like the show. Oh, but I did go back and look at some of the previous stats because then I was like, huh, so I'm paying attention. I looked at this year's, and I was like, I wonder what last year's was or the year before that. And I think this survey comes out every two years because I didn't see one for 2021. But I did find the survey results for 2020, which we were in the number one spot for 2020, and Remote Ruby was in the second spot. So I feel like now we've got a really nice, healthy podcasting war situation going on to see who can grab the first spot. We've got two years, everybody, to see who [laughs] grabs the number one spot. That's a lot of prep time for a competition. CHRIS: Yeah, I feel like we should be like, I don't know, planning elaborate pranks on them or something like that now. Is that where this is at? It's something like that, I think. STEPH: I think so. I think this is where you put like sky frosting inside someone's suitcase, and that's the type of prank that you play. [laughs] CHRIS: The best of pranks. STEPH: We'll definitely put together a little task force. And we'll start thinking of pranks that we all need to start playing on each other for the podcasting wars that we're entering for the next few years. But anywho, what's going on in your world? CHRIS: Let's see, what's going on in my world? A fun thing happened recently. I had a chance to reflect back on some architectural choices that we've made in the Sagewell platform. And one of those specific choices is how we've approached building our native mobile apps. We made what some listeners may remember is an interesting set of choices. In particular, in Episode 328, which we'll include a link to in the show notes, I shared with you the approach that we're doing, which is basically like, Inertia is great, web user great. We like the web as a platform. What if we were to wrap it in a native shell and find this interesting and somewhat unique hybrid trade-off point? And so, at that point, we were building it. We had most of it built out, and things were going quite well. I think we maybe had the iOS app in the store and the Android app approaching the store or something like that. At this point, both apps have been released to the store, so they are live. Production users are signing in. It's wonderful. But I had a moment in the past couple of weeks to reassess or look at that set of choices and evaluate it. And thankfully, I'm happy with the choices that we've made. So that's good. But to get into the specifics, there were two things that happened that really, really framed the choice that we made, so one was we introduced a major new feature. We basically overhauled the first-run experience, the onboarding that users experience, and added a new, pretty fundamental facet to the platform. It's a bunch of new screens, and flows, and error states, and all of this complexity. And in the process, we iterated on it a bunch. Like, first, it looked like this, and then we changed the order of the screens and switched out the error messages, and et cetera, et cetera. And I'll be honest, we never even thought about the mobile apps. It just wasn't even a consideration. And interestingly, we did as a final check before going fully live and releasing this out to the full production audience; we did spot check it in the mobile apps, and it didn't work. But it didn't work for a very specific, boring, technical reason that we were able to resolve. It has to do with iframes and WebViews and embedded something, something. And we had to set a flag. Thankfully, it was solvable without a deploy of the native mobile apps. And otherwise, we never thought about the native apps. Specifically, we were able to add this fundamental set of features to our platform. And they just worked in native mobile. And they were the same as they roughly are if you're on a mobile WebView or if you're on a desktop web, you know, slightly different in terms of form factor. But the functionality was all the same. And critically, the error states and the edge cases and the flow, there's so much to think about when you're adding a nontrivial feature to an app. And the fact that we didn't have to consider it really spoke to the choice that we made here. And again, to name it, the choice that we made is we're basically just reusing the same WebViews, the same Rails controllers, and the same what are Svelte components under the hood but the same essentially view layer as well. And we are wrapping that in a native iOS. It's a Swift application shell, and on Android, it's a Kotlin application shell. But under the hood, it's the same web stuff. And that was really great. We just got these new features. And you know what? If we have to rip that whole set of functionality out, again, we won't need to deploy. We won't need to rethink it. Or, if we want to subtly tweak it, we can do that. If we want to think about feature flags or analytics, or error states or error reporting, all of this just naturally falls out of the approach that we took. And that was really wonderful. STEPH: That's super nice. I also love this saga of like, you made a choice, and then you're coming back to revisit and share how it's going. So as someone who's never done this before, in regards of wrapping an application in the manner that you have and then publishing it and distributing it that way, what does that process look like? Is this one of those like you run a command, and literally, it's going to wrap the application and then make it hostable on the different mobile app stores? Or what's that? Am I oversimplifying the process? What does that look like? CHRIS: I think there are a lot of platforms or frameworks I think would probably be the better word like Capacitor is something that comes to mind or Ionic or Expo. There are a handful of them that are a little more fully featured in what they provide. So you just point us at your React Views and whatnot, and we'll wrap that up, and it'll be great. But those are for, I may be overgeneralizing here, but my understanding is those are for more heavy client-side bundles that are talking to a common API. And so you're basically taking your same rich client-side application and bundling that up for reuse on the native app, the native app platforms. And so I think those do have some release to the store sort of thing. In our case, we went a little bit further with that integration wrapper thing that we built. So that is a thing that we maintain. We have a Sagewell iOS repo and a Sagewell Android repo. There's a bunch of Swift and Kotlin code, respectively, in each of them, and we deploy to the stores manually. We're doing that whole process. But critically, the code that is in each of those repositories is just the bridge glue code that says, oh, when this Inertia navigation event happens, I'm going to push a WebView to the navigation stack. And that's what that is. I'm going to render the tab bar of buttons at the bottom with the navigation elements that I get from the server. But it's very much server-driven UI, is the way that I would describe it. And it's wrapping WebViews versus actually having the whole client bundle wrapped up in the thing. It's unfortunately subtle to try and talk through on the radio, but yeah. [laughs] STEPH: You're doing great; this is helping. So if there's a change that you want to make, you go to the Rails application, and you make that change. And then do you need to update anything on that iOS repo? It sounds like you don't, which then you don't have to push a new update to the store. CHRIS: Correct. For the vast majority of things, we do not need to make any changes. It's very rare for us to deploy the iOS or the Android app is a different way to put it or to push new releases to the store. It happens we may want to add a new feature to the sort of bridge layer that we built, but increasingly, those are rare. And now it's basically like, yeah, we're just wrapping those WebViews, and it's going great. And again, to name it, it's a trade-off. It's an intentional trade-off that we've made. We're never going to have the richest, most deep platform integration, smooth experience. We are making a small trade-off on that front. But given where we're at as an organization, given how early we are, how much iteration and change, we chose an architecture that optimizes for that change. And so again, like what you just said, yeah, I can...you know how it's really nice to be able to deploy six times a day on a web app, and that's a very straightforward thing to do? It is not so straightforward in the native mobile world. And so, we now have afforded ourselves the ability to do that. But critically, and this is the fun part in my mind, have the trade-offs in the controls. So if we were just like, it's just a WebView, and that's it, and we put it in the stores, and we're done, that is too far of an extreme in my mind. I think the performance trade-offs, the experience trade-offs, it wouldn't feel like a native app like in a deep way, in a problematic way. And so as an example, we have a navigation bar at the top of our app, particularly on iOS, that is native iOS navigation. And we have a tab bar at the bottom, which is native tab UI element. I forget actually what it's called, but it's those elements. And we hide the web application navigation when we're in the mobile context. So we actually swap those out and say, like, let's actually promote these to formal native functionality. We also, within our UI on the web, have a persistent button in the top right corner of your screen that says, "Need help? Reach out to your retirement advocate." who is the person that you get to work with. You can send questions, et cetera, et cetera. It's this little help sidebar drawer thing that pops out. And we have that as a persistent HTML button in the top corner of the web frame. But when we're on native, we push that up as a distinct element in the native UI section. And then again, the bridge that I'm talking about allows for bi-directional communication between the JavaScript side and the native side or the native side and the JavaScript side. And so it's those sorts of pieces that have now afforded us all of the freedom to tinker, and we don't need to re-release where we're like, oh, we want to add a new weird button that does a thing in the WebView when you click on a button outside the WebView. We now just have that built-in. STEPH: Yeah, I really like the flexibility that you're describing. When you promoted those elements to be more native-friendly so, like the navigation or the footer or the little get help chat, is that something that then your team implemented in like the iOS or the Kotlin repo? Okay, I see you nodding, but other people can't see that, so...[laughs] CHRIS: Yeah. I was going to also say the words, but yes, those are now implemented as native parts. So the thing that we built isn't purely agnostic decoupled. It is Sagewell-specific; a lot of it is low-level. Like, let's say we want to wrap an Inertia app in a native mobile wrapper. Like, 90% of the code in it is that, but then there are little bits that are like, and put a button up there. And that button is the Sagewell button. And so it's not entirely decoupled from us. But it mostly is this agnostic bridge to connect things together. STEPH: Yeah, the way you're describing it sounds really nice in terms of you're able to get out the app quickly and have a mobile app quickly that works on both platforms, and then you're still able to deploy changes without having to push that. That was always my biggest mental, or emotional hurdle with the idea of mobile development was the concept of that you really had to batch everything together and then submit it for review and approval and then get it released. And then you got to hope people then upgrade and get the newest version. And it just felt like such a process, not that I ever did much of it. This was all just even watching like the mobile team and all the work that they had to do. And I had sympathy pains for them. But the fact that this approach allows you to avoid a lot of that but still have some nice, customized, more native elements. Yeah, I'm basically just recapping everything you said because I like all of it. CHRIS: Well, thank you, friend. Like I said, I've really enjoyed it, and similar to you, I'm addicted to the feedback loop of the web. It's beautiful. I can deploy ten times or however many I want. Anytime I want, I can push out a new version. And that ability to iterate, to test, to explore, to tweak, to not have to do as much formal testing upfront because I'm terrified that if a bug sneaks out, then, it'll take me two weeks to address it; it just is so, so freeing. And so to give that up moving into a native context. Perhaps I'm fighting too hard to hold on to my dream of the ability to rapidly iterate. But I really do believe in that and especially for where we're at as an organization right now. But, and a critical but here, again, it's a trade-off like anything else. And recently, I happened to be out about in the town, and I decided, oh, you know what? Let me open up the app. Let me see what it's like. And I wasn't on great internet. And so I open the app, and it loads because, you know, it's a native app, so it pops up. But then the thing that actually happened is a loading spinner in the middle of the screen and sort of a gray nothing for a little while until the server request to fetch the necessary UI elements to render the login screen appeared. And that experience was not great. In particular, that experience is core to the experience of using the app every single time. Every time you use it, you're going to have a bad time because we're re-downloading that UI element. And there's caching, and there's things that could happen there to help with that. But fundamentally, that experience is going to be a pretty common one. It's the first thing that you experience when you're opening the app. And so I noticed that and I chatted with the team, and I was like, hey, I feel like this is actually something that fixing this I think would really fundamentally move us along that spectrum of like, we've definitely made some trade-offs here. But overall, it feels snappy and like a native app. And so, we opted to prioritize work on a native login screen for both platforms. This also allows us to more deeply integrate. So particularly, we're going to get biometric logins like fingerprints or face scans, or whatever it is. But critically, it's that experience of like, I open the Sagewell native app on my iOS phone, and then it loads immediately. And then I show it my face like we do these days, and then it opens up and shows me everything that I want to see inside of it. And it's that first-run experience that feels worth the extra effort and the constraints. Because now that it's native mobile, that means in order to change it, we have to do a deploy, not a deploy, release; that's what they call it in the native world. [laughs] You can tell I'm well-versed in this ecosystem. But yeah, we're now choosing that trade-off. And what I really liked about this sort of set of things like the feature that we were able to just accidentally get for free on native because that's how this thing is built. And then likewise, the choice to opt into a fully native login screen like having that lever, having that control over I'm going to optimize for iteration generally, but where it's important, we want to optimize for performance and experience. And now we have this little slider that we can go back and forth. And frankly, we could choose to screen by screen just slowly replace everything in the app with true native WebViews backed by APIs. And we could Ship of Theseus style replace every element of the app with true native mobile things until none of the old bridge code exists. And our users, in theory, would never know. Having that flexibility is really nice given the trade-off and the choice that we've made. STEPH: You said a word there that I missed. You said ship something style. CHRIS: Ship of Theseus. STEPH: What is that? CHRIS: It's like an old biblical story, I want to say, but it's basically the idea of, like, you have the ship. And then some boards start to rot out, so replace those boards. And then the mast breaks, you replace the mast. And slowly, you've replaced every element on the ship. Is it still the same ship at that point? And so it's sort of a philosophical question. So if we replace every single view in this app with a native view, is it still the same map? Philosophers will philosophize about it forever, but whatever. As long as we get to keep iterating and shipping software, then I'm happy. STEPH: [laughs] Y'all philosophize. That's that word, right? CHRIS: Yeah. STEPH: And do your philosopher thing. We'll just keep building and shipping. CHRIS: I don't know if I pronounced it right. It's like either Theseus or Theseus, and I'm sure I said the wrong one. And now that I've said the other, I'm sure both of them are wrong somehow. It's like a USB where there's up and down, and yet somehow it takes three tries. So anyway, I may have mispronounced it, and I may be misattributing it, but that's the idea I was going for. STEPH: Well, given I wasn't even familiar with the word until just now, I'm going to give both pronunciations a thumbs up. I also really like how you decided that for the login screen, that's the area that you don't want people to wait because I agree if you're opening an application or opening...maybe it's the first time, maybe it's the 100th time. Who knows? But that feels important. Like, that needs to be snappy. I need to know it's responsive. And it builds trust from the minute that I clicked on that application. And if it takes a long time, I just immediately I'm like, what are y'all doing? Are y'all real? Do you know what you're doing over there? So I like how you focused on that experience. But then once I log in, like if something is slow to log me in, I will make up excuses for the application all day where I'm like, well, you know, maybe it's my connection. It's fine. I can wait for the next screen to load. That feels more reasonable. And it doesn't undermine my trust nearly as much as when I first click on the app. So that feels like a really nice trade-off as well, or at least a nice area that you've improved while still having those other trade-offs and benefits that you mentioned. CHRIS: To highlight it, you used a phrase there which I really liked. Like, it's building trust. If something's a little bit off in that first run experience every single time, then it kind of puts a question in the back of your head, maybe not even consciously. But you're just kind of looking at it, and you're like, what are you doing there? What are you up to, friend? Humans say to the apps they use on their phone. That's normal, right? When you talk... But to name it, we've also done a round of performance work throughout the app. And so there are a couple of layers to it. But it was work that we had planned for a while, but we kept deferring. But now that we're seeing more usage of the native apps, the native apps experience the same surface area of performance stuff but all the more so because they may be on degraded network connections, et cetera. And so this is another example where this whole thing kind of pays off. The performance work that we did affects everything. It affects the web. It's the same under the hood. It's let's reduce the network requests that we're making in the payloads that we're sending, particularly the network requests to upstream things, so like the banking partner that we're using and those APIs, like, collating all the data to then render the screen. Because of Inertia, we only have a single sort of back and forth conversation via the API as opposed to I think it's pretty common to have like seven different APIs and four different spinners on the screen. We're not doing that, none of that on my watch. [chuckles] But we minimize the background calls to the other parties that we're integrating with. And then, we reduce the payload of data that we're sending on each request. And each of those were like, we had to think about things and tweak and poke, but again it's uniform. So mobile web has that now, desktop web has that now. Android, iOS, they all just inherited it sort of that just happened one day without a deploy or release, without a release of either of the native mobile apps. We did deploy to the web to make that happen, but that's easy. I can do that a bunch of times a day. One last thing I want to share as we're on this topic of trade-offs and levers, there was a really great conference talk that I watched recently, which was Ryan Florence of remix.run also React Router fame if you're familiar with him from that. But he was talking about the most recent version of Remix, which is their meta framework on top of React. But they've done some really interesting stuff around processing data, fetching data, when and how to sequence that. And again, that thing that I talked about of nine different loading spinners on the screen, Remix is taking a very different approach but is targeting that same thing of like, that's not great for user experience. Cumulative layout shift being the actual number that you can monitor for this. But in that talk, there are features that they've added to Remix as a framework where you can just decide, like, do we wait for this or do we not? Do we make sure we have all of the data, or do we say, you know what? Actually, this is going to be below the fold. So it's okay to defer loading this until after we send down the first payload. And then we'll kick in, and we'll do it from the client-side. But it's this wonderful feature of the framework that they're adding in where there's basically just a keyword that you can add to sort of toggle that behavior. And again, it's this idea of like trade-offs. Are we okay with more layout shift, or are we okay with more waiting? Which is it that we're going to optimize for? And I really love that idea of putting that power very simply in the hands of the developers to make those trade-off decisions and optimize over time for what's important. So we'll share a link to that talk in the show notes as well. But it was very much in the same space of like, how do I have the power to decide and to change my mind over time? That's what I want. But yeah, with that, I think that's enough of me updating on the mobile app. I'll continue to share as new things happen. But again, I'm at this point very happy with where we're at. So yeah, it's been fun. But yeah, what else is up in your world? STEPH: I have a dear Gerrit message that I wrote earlier, so I want to share that with you. Gerrit is the system that we're using for when we push up code changes that then manages very similar in the competitive space of like GitHub and GitLab, and Bitbucket. And so the team that I'm working with we are using Gerrit. And Gerrit and I, you know, we get along for the most part. We've managed to have a working relationship. [chuckles] But this week, I wrote my dear Gerrit letter is that I really miss being able to tell a story with my commit messages. That is the biggest pain that I'm feeling right now. So for anyone that's less familiar or if you already are familiar with Gerrit, each change that Gerrit shows represents a single commit that's under review. And each change is identified by a Change-Id. So the basic concept of Gerrit is that you only have one commit per review. So if you were to translate that to GitHub terminology, every pull request is only going to have one commit, and so you really can't push up multiple. And so, where that has been causing me the most pain is I miss being able to tell a story. So like even simple stories that are like, hey, I removed something that's not used. I love separating that type of stuff into its own commit just so then people can see that as they're going through review. Now, before I merge, I'm likely to squash, and that doesn't feel important that it needs to be its own commit. That's really just for the reviewer so they can follow along for the changes. But the other one, I can slowly get over that one. Because essentially, the way I get around that is then when I do push up my code for review, is I then go through my change request, and then I just add comments. So I will highlight that line and say, "Hey, I'm removing this because it's not in use." And so, I found a workaround for that one. But the one I haven't found a workaround for is that I don't push up my local work very often because I love having lots of local, tiny, green commits so that way I can know the progress that I'm at. I know where I'm headed. Also, I have a safe space to roll back to, but then that means that I may have five or six commits that I have locally, but I haven't pushed up somewhere. And that is bothering me more and more hour by hour the more I think about it that I can't push stuff up because it makes me nervous. Because, I mean, usually, at least by the end of the day, I push everything up, so it's stored somewhere. And I don't have to worry about that work disappearing. Now I am working on a dev machine. So there is that aspect of it's technically...it's not even on my local machine. It is stored somewhere that I should still be able to access. CHRIS: What's a dev machine? The way you're saying it, it sounds like it's a virtual machine, not like a laptop. But what's a dev machine? STEPH: Good question. So the dev machine is a remote server or remote machine that then I am accessing, and then that's where I'm performing. That's where I'm writing all of my work. And then that's also kind of the benefit is everything is not local; it's controlled by the team. So then that also means that other teams, other individuals can help set up these environments for future developers. So then you have that consistency across everyone's working with the same Rails version, or gems, or has access to the same tools. So in that sense, my work isn't just on my laptop because then that would really worry me because then I've got nowhere...it's not backed up anywhere. So at least it is somewhere it's being stored that then could be accessed by someone. So actually, now, as I'm talking this through, that does help alleviate my concern about this a bit. [laughs] But I still miss it; I still miss being able to just push up my work and then have multiple commits. And I looked into it because I was like, well, maybe I'm misunderstanding something about Gerrit, and there's a way around this. And that's still always a chance. But from the research that I've done, it doesn't seem to be. And there are actually two very fiery takes that I saw that I have to share because they made me laugh. When I was Googling, the question of like, "Can I push up multiple commits to one single Gerrit CR? Or is there just a way to, like, can I have this concept of like a branch and then I have many commits, but then I turn it into one CR? Whatever the world would give me. What do they have? [laughs] I'm laughing just looking at this now. One of the responses was, have you tried squashing your commits into one commit? And I was like, [laughs] "Yeah, that's not what I had in mind, but sure." And then the other one, this is the more fiery take. They were very defensive about Gerrit, and they wrote that "People who don't like Gerrit usually just hack shit together. They cut corners and love squashing commits or throwing away history. And those people hate Gerrit. Developers who care love it. It's definitely possible and easy to produce agile software." And I just...that made me laugh. I was like, cool, I'm a developer that cuts corners and loves squashing commits. [laughs] CHRIS: So you don't care is what that take says. STEPH: I'm a developer who does not care. CHRIS: You know, Steph, I've worked with you for a while. And I've been looking for the opportunity to have this hard conversation with you. But I just wish you cared a little more about the software that you're writing, about the people that you're working with, about the commits that you're authoring. I just see it in every facet of your work. You just don't care. To be very clear for anyone listening at home, that is the deepest of sarcasm that I can make. Steph cares so very much. It's one of the things that I really enjoy about you. STEPH: I mean, we had the episode about toxic traits. This would have been the perfect time to confront me about my lack of caring about software and the processes that we have. So winding down on that saga, it seems to be the answer is no, friend; I cannot push up multiple commits. Oh, I tried to hack it. I am someone that tries to hack shit together because I tried to get around it just to see what would happen. [laughs] Because the docs had suggested that each change is identified by a Change-Id. And I was like, hmm, so what if there were two commits that had the same Change-Id, would Gerrit treat those as patch sets? Because right now, when you push up a change, you can see all the different patch sets, so that's nice. So that's a nice feature of Gerrit as you can see the history of, like, someone pushed up this change. They took in some feedback. They pushed up a new change. And so that history is there for each push that someone has provided. And I wondered maybe if they had the same Change-Id that then the patch sets would show the first commit and then the second commit. And so I manually altered the commits two of them to reference the same Change-Id. And I have to say, Gerrit was on to me because they gave me a very nice error message that said, "Same Change-Id and multiple changes. Squash the commits with the same Change-Ids or ensure Change-Ids are unique for each commit. And I thought, dang, Gerrit, you saw me coming. [laughs] So that didn't work either. I'm still in a world of where I now wait. I wait until I'm ready for someone to review stuff, and I have to squash everything, and then I go comment on my CRs to help out reviewers. CHRIS: I really like the emotional backdrop that you provided here where you're spending a minute; you're like, you know what? Maybe it's me. And there's the classic Seymour Skinner principle from The Simpsons. Am I out of touch? No, it's the children who are wrong. [laughs] And I liked that you took us on a whole tour of that. You're like, maybe it's me. I'll maybe read up. Nope, nope. So yeah, that's rough. There's a really interesting thing of tools constraining you. And then sometimes being like, I'm just going to yield control and back away and accept this thing that doesn't feel right to me. Like, Prettier does a bunch of stuff that I really don't like. It shapes code in a way, and I'm just like, no, that's not...nope, you know what? I've chosen to never care about this again. And there's so much utility in that choice. And so I've had that work out really well. Like with Prettier, that's a great example whereby yielding control over to this tool and just saying, you know what? Whatever you produce, that is our format; I don't care. And we're not going to talk about it, and that's that. That's been really useful for myself and for the teams that I'm on to just all kind of adopt that mindset and be like, yeah, no, it may not be what I would choose but whatever. And then we have nice formatted code; it's great. It happens automatically, love it. But then there are those times where I'm like; I tried to do that because I've had success with that mindset of being like, I know my natural thing is to try and micromanage and control every little bit of this code. But remember that time where it worked out really well for me to be like, I don't care, I'm just going to not care about this thing? And I try to not care about some stuff, which it sounds like that's what you're doing right here. [laughs] And you're like, I tried to not care, but I care. I care so much. And now you're in that [chuckles] complicated space. So I feel for you, Steph. I'm sorry you're in that complicated space of caring so much and not being able to turn that off [laughs] nor configure the software to do the thing you want. STEPH: I appreciate it. I should also share that the team that I'm working with they also don't love this. Like, they don't love Gerrit. So when I shared in the Slack channel my dear Gerrit message, they're both like, "Yeah, we feel you. [laughs] Like, we're in the same spot," which was also helpful because I just wanted to validate like, this is the pain I'm feeling. Is someone else doing something clever or different that I just don't know about? And so that was very helpful for them to say, "Nope, we feel you. We're in the same spot. And this is just the state that we're in." I think they have started transitioning some other repos over to GitLab and have several repos in Gitlab, but this one is still currently using Gerrit. So they very much commiserate with some of the things that I'm feeling and understand. And this does feel like one of those areas where I do care deeply. And frankly, this is one of those spaces that I do care about, but it's also like, I can work around it. There are some reasonable things that I can do, and it's fine as we just talked through. Like, the fact that my commits are not just locally on my machine already makes me feel better now that I've really processed that. So there are lower risks. It is more of just like a workflow. It's just, you know, it's crushing my work vibe. CHRIS: Harshing your buzz. STEPH: In the great words of Queen Elsa, I gotta let it go. This is the thing I'm letting go. So that's kind of what's going on in my world. What else is going on in your world? CHRIS: Well, first and foremost, fantastic reference and segue. I really liked that. But yeah, let's see, [laughs] what else is going on in my world? We had an interesting thing happen last week. So we had an outage on the platform last week. And then we had an incident review today, so a formal sort of post-mortem incident review. There are a couple of different names that folks have given to these. But this is a practice that we want to build within our engineering culture is when stuff goes wrong, we want to make sure that we have meaningful conversations around to try to address the root causes. Ideally, blameless is a word that gets used often in this context. And I've heard folks sort of take either side of that. Like, it's critical that it's blameless so that it doesn't feel like it's an attack. But also, like, I don't know, if one person did something, we should say that. So finding that gentle middle ground of having honest, real conversations but in a context of safety. Like, we're all going to make mistakes. We're all going to ship bugs; let's be clear about that. And so it's okay to sort of...anyway, that's about the process. We had an outage. The specific outage was that we have introduced a new process. This is a Sidekiq process to work off a specific queue. So we wanted that to have discrete treatment. That had been running, and then it stopped running; we still don't know why. So we never got to the root-root cause. Well, we know what the mechanism was, which was the dyno count for that process was at zero. And so, eventually, we found a bunch of jobs backed up in the Sidekiq admin. We're like, that's weird. And then, we went over to Heroku's configuration dashboard. And we saw, huh, that's weird. There are zero dynos processing this. That wasn't true yesterday. But unfortunately, Heroku doesn't log or have an audit trail around changes to those process counts. It's just not available. So that's unfortunate. And then the actual question of like, how did this happen? It probably had to be someone on the team. So there is like, someone did a thing. But that is almost immaterial because, again, people are going to do things, bugs will get shipped, et cetera. So the conversation very quickly turned to observability and understanding. I think we've done a pretty good job of instrumenting error reporting and being quite responsive to that, making sure the signal-to-noise ratio is very actionable. So if we see a bug or a Sentry alert come through, we're able to triage that pretty quickly, act on it where it is a real bug, understand where it's a bit of noise in the system, that sort of thing. But in this case, there were no errors. There was no Sentry. There was nothing; there was the absence of something. And so it was this really interesting case of that's where observability, I think, can really come in and help. So the idea of what can we do here? Well, we can monitor the count of jobs backed up in Sidekiq queue. That's one option. We could do some threshold alerting around the throughput of processed events coming from this other backend. There are a bunch of different ways, but it basically pushed us in the direction of doubling down and reinforcing the foundation of our observability within the platform. So we're just kicking that mini-project off now, but it is something we're like, yeah, we feel like we could add some here. In particular, we recently added Datadog to the stack. So we now have Datadog to aggregate our logs and ideally do some metric analysis, those sort of things, build some dashboards, et cetera. I haven't explored Datadog much thus far. But my sense is they've got the whiz-bang things that we need here. But yeah, it was an interesting outage. That wasn't fun. The incident conversation was actually a good conversation as a team. And then the outcome of like, how do we double down on observability? I'm actually quite excited for. STEPH: This is a fun moment for me because I have either joined teams that didn't have Datadog or have any of that sort of observability built into their system or that sort of dashboard that people go to. Or I've joined teams, and they already have it, and then nobody or people rarely look at it. And so I'm always intrigued between like what's that catalyst that then sparked a team to then go ahead and add this? And so I'm excited to hear you're in that moment of like, we need more observability. How do we go about this? And as soon as you said Datadog, I was like, yeah, that sounds nice because then it sounds like a place that you can check on to make sure that everything is still running. But then there's still also that manual process where I'm presuming unless there's something else you have in mind. There's still that manual process of someone has to check the dashboard; someone then has to understand if there's no count, no squiggly lines, that's a bad thing and to raise a concern. So I'm intrigued with my own initial reaction of, like, yeah, that sounds great. But now I'm also thinking about it still adds a lot of...the responsibility is still on a human to think of this thing and to go check it. Versus if there's something that gets sent to someone to alert you and say like, "Hey, this queue hasn't been processed in 48 hours. There may be a concern that actually feels nicer." It feels safer. CHRIS: Oh yeah, definitely. I think observability is this category of tools and workflows and whatnot. But I think what you're describing of proactive alerting that's the ideal. And so it would be wonderful if I never had to look at any of these tools ever. And I just knew if I got, let's say, it's PagerDuty connected up whatever, and I got a push notification from PagerDuty saying, "Hey, go look at this thing." That's all I ever need to think about. It's like, well, I haven't gotten a PagerDuty in a while, so everything must be fine, and having a deep trust in that. Similar to like, if we have a great test suite and it's green, I feel confident deploying the sort of absence of an alert being the thing that I can trust. But right now, we're early enough in this journey that I think what we need to do is stand up a bunch of these different graphs and charts and metric analysis and aggregations and whatnot, and then start to squint at it for a while and be like, which of these would I be really concerned if it started to wibble? And then you can figure the alerting around said wibble rate. And that's the dream. That's where we want to get to, but I think we've got to crawl, walk, run on this. So it'll be an adventure. This is very much the like; we're starting a thing. I'll tell you about it more when we've done it. But what you're describing is exactly what we want to get to. STEPH: I love wibble rate. That's my new measurement I'm going to start using for everything. It's funny, as you're bringing this up, it's making me think about the past week that Joël Quenneville and I have had with our client work. Because a somewhat similar situation came up in regards where something happened, and something was broken. And it seemed it was hard to define exactly what moment caused that to break and what was going on. But it had a big impact on the team because it essentially meant none of the bills were going through. And so that's a big situation when you got 100-plus people that are pushing up code and expecting some of the build processes to run. But it was one of those that the more we dug into it, the more it seemed very rare that it would happen. So, in this case, as a sort of a juxtaposition to your scenario, we actually took the opposite approach of where we're like; this is rare. But we did load up a lot of contexts. Actually, I was thinking back to the advice that you gave me in a previous episode where I was talking about at what point do you dig in versus try to stay at surface level? And this was one of those, like, we've spent a couple of days on getting context for this and understanding. So it felt really important and worthwhile to then invest a little bit more time to then document it. But then we still went with the simplest approach of like, this is weird. It shouldn't happen again. We think we understand it but then let's add a little bit of documentation or wiki page around like, hey, if you do run into this, here are some steps that will fix everything. And then, if you need to use this, let somebody know because this is so odd it shouldn't happen. So we took that approach in this case where we didn't increase the observability. It was more like we provided a fire extinguisher very close to the location in case it happens. And so that way, it's there should the need arise, but we're hoping it just never gets used. We're also in the process of changing how a lot of that logic works. So we didn't really want to optimize for observability into a system that is actively being changed because it should look very different in upcoming months. But overall, I love the conversations that you bring about observability, and I'm excited to hear about what wibble rates you decide to add to your Datadog dashboard. CHRIS: There's a delicate art and science to the selection of the wibble rates. So I will certainly report back as we get into that work. But with that, shall we wrap up? STEPH: Let's wrap up. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Daniel talks to Manton about his experience debugging an AppKit issue in Micro.blog, and his satisfaction with AppKit's debugging ease. They compare the relative debuggability of SwiftUI, AppKit and JavaScript web frameworks. Daniel talks about diving into a long-postponed effort to migrate away from legacy WebView framework to the newer WKWebView design. The post Episode 515: In The Actor’s Studio appeared first on Core Intuition.

http://9chat-e.mynt.work/?c=radio/contents&id=714 プログラミング学習に役立つ情報をお伝えするラジオ番組

http://9chat-e.mynt.work/?c=radio/contents&id=714 プログラミング学習に役立つ情報をお伝えするラジオ番組

Chris is helping with efforts to introduce security, practices, and policies at Sagewell. Right now, they are refining the usage of 1Password to standardize passwords and secure information. He also shares (what he believes) is a terrible idea around fixing inconsistencies around symbols and strings. Steph shares an update around factories. Also, at Sagewell, Chris is helping to build mobile apps, one for iOS and one for Android, and is considering pursuing having them be all native. Good idea? Terrible idea? Chris and Steph riff on that a bit. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Services down? New Relic (https://newrelic.com/bikeshed) offers full stack visibility with 16 different monitoring products in a single platform. GitHub - alassek/activerecord-pg_enum (https://github.com/alassek/activerecord-pg_enum): Integrate PostgreSQL's enumerated types with the Rails enum feature Feature #7792: Make symbols and strings the same thing (https://bugs.ruby-lang.org/issues/7792) - Ruby master - Ruby Issue Tracking System RailsConf 2016 - Turbolinks 5: I Can't Believe It's Not Native! by Sam Stephenson (https://www.youtube.com/watch?v=SWEts0rlezA) GitHub - hotwired/turbo-ios (https://github.com/hotwired/turbo-ios): iOS framework for making Turbo native apps Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Weird stuff happens when we sing, Steph. STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world? CHRIS: Hello, Steph. What is new in my world? We are continuing with some of the efforts that we're doing to introduce security, and practices, and policies, and all those fun sorts of things at the organization. One of the things that this is pushing on is we are further refining our usage of 1Password at the company as a way to standardize passwords and secure information and how we store that, how we move it around, as well as integrating SSL, and all those other fun fancier things. But I'm personally historically a LastPass user, and now I'm getting to experience 1Password. So now I'm a child of two worlds, and it's terrible, and I hate it. I hate every moment of this existence. So what I need to do is move over to 1Password, but now I'm in that space where I'm like, I can see the flaws of both systems. This is terrible. I don't like it. 1Password does seem to be great; I will say that. There's one really interesting thing about 1Password. I'm interested...you're a 1Password user, right? STEPH: I'm not; I use LastPass. I'm also a child of two worlds because we use 1Password for thoughtbot stuff, but then I use LastPass for my stuff. CHRIS: Gotcha. Okay, so you survive in the middle space. I'm slowly trying to move everything over because I think 1Password has a little bit more of what I'm going for. And I would like, frankly, to be in one cohesive, consistent space, although having two different accounts seems interesting. I definitely can handle it. But knowing which I'm in and how to save a password to one versus the other, it's a whole thing. The one thing that I find really interesting though is 1Password has a feature where it will do two-factor, two-factor authentication. It will do that for you. Specifically, it's doing, as far as I can tell, the TOTP. I don't know what that acronym stands for, but it's the fancy type of two-factor, so not SMS, not text message-based, and not others like WebAuthn is a thing that I've heard of, which I don't know if that is distinct from YubiKey or hardware keys. So there's a bunch I'm trying to learn about this space a little bit more. I'm very interested in the hardware keys because those seem cool. WebAuthn seems like a new standard. That sounds cool. Don't know anything about it, though. So mostly, I know about SMS, and I do not like that one. I do not want to use text messages because, as far as I understand it, they're not super secure. So that's not the space I want to be in. But the TOTP, the Google Authenticator, or Authy, or that space of password or two-factor code generation tools those seem good. And 1Password has a feature where they're like, hey, yeah, sure, we'll have your password and your two-factor. And so they grab the QR code, which is typically the QR code is a way, as far as I understand it, to share the seed. And then, that seed is used by an algorithm to generate the current code value for a given point in time. So it takes like, given that seed and the current timestamp, we will generate you the relevant code, which can then be verified on the far side. But that seed only exists for one moment in time, et cetera, et cetera. But I've always thought of it as this separate thing. The idea of having that all in one system is interesting and kind of scary to me. But as I think about it, I'm like, if 1Password or LastPass, in either case, gets compromised, we're all done. Like, this is over. We should throw in our cards, give away the internet. This whole experiment has failed is my sense. But it was very interesting because I had not seen this. I've always had these as separate systems. So for me, I have had LastPass, and I have Authy on my phone for the two-factor. But it's frankly very clunky, and I don't like it. And the 1Password thing is fantastic where I say like, yeah, 1Password, fill in my password and username, and then also fill in my two-factor because you have it. This is great. But, and this is where I hesitate, and I don't know, I will say this: I trust that 1Password has thought about this deeply way more than I can and have come to a place of deep confidence that this is a fine and okay thing to do. But I'm still intrigued. What's going on here? STEPH: That was a lot. I have so many thoughts. [laughs] CHRIS: Sorry, that was a lot of words, a lot of ideas, a lot of space there. It's just where I'm at. STEPH: People couldn't hear me, but I was laughing when you were talking about LastPass or if these accounts get hacked in. And I'm imagining someone who uses the combination of their cat's name and their birthday as their password and then like, aha, I win. [laughs] It's like, no, we just all lose. [laughs] But that amused me. Going back, you talked about having it all in one place. And that actually doesn't surprise me that we're different in this area. Because you also like all of your email...you like one source of everything, which makes so much sense, but I'm different. And with these accounts, I like that I have the distinction between all of thoughtbot is in 1Password while all of mine is in LastPass because it's just a very clear delineation between those two accounts. And I'm sure both of these platforms have figured out a really good way to then separate those two. But I just remembered there was someone at thoughtbot that accidentally...because they have everything in 1Password, they accidentally shared their personal vault with a client. And so they were just typing in Slack. They're like, "Oh, shit, oh shit, like, how do I undo this?" And we're all just watching like, "We don't know. But please let us know how it turns out." [laughs] It turned out fine. I think they actually realized they hadn't fully shared it but based on the UI they thought that they had. So it all turned out okay. So that just lives with me. I'm a little scared of that now now that I know that story. So watch out, friends. CHRIS: Oh, wow. Well, now, yeah, I'm also now scared of that. I wasn't, but now I am. STEPH: And I forgot the other thoughts now. Those were my two main thoughts based on the journey that you've shared. CHRIS: Particular to the thing you were sharing there, yes, now I will have nightmares about it. But also, it feels manageable because they're both entirely different accounts, and then also within that, there are different vaults. So as I'm building up the password infrastructure at Sagewell, there's going to be different...like, the dev team will probably have one vault and then a shared vault for the dev team. And then other teams within the organization will have that. And so it feels like there are at least structures within the tool to manage that. But mostly, my consideration is around the two-factor thing. And like, is this reasonable to do? And again, I'm sure 1Password has thought way harder than I have about it. And I trust that they're like, yeah, this seems fine that they're not just like, I don't know, it doesn't seem bad. They're like, no, no, definitively for information-theoretic reasons, this is fine. But it was surprising. STEPH: That was it. The other comment that you made about two-factor auth that resonated with me because there was a point not that long ago where we have one of those, either New Relic or I forget which account it was, but it was with the systems. We really only needed one person to have access, but every now and then, someone else may need to access that account. And so we wanted to be able to store it in 1Password or LastPass somewhere like that. But then the two-factor auth was a problem because then you had to coordinate with that other person to say, "Hey, I just need to check something. Would you let me in?" And because we could then leverage that feature, then we could just store all of it. And then that person could just go to 1Password or LastPass and then have access to all of it, and that was really nice. That was a very nice solution to I want to say it was a small problem but yet also very important for team happiness. So that was really nice. CHRIS: The amount of times that I've been like, "I just tried to sign in to the shared account, and it says that it sent a two-factor request to somebody's phone, but it didn't tell me whose phone. And I'm not sure if we know who that person is or if that person's still around," that version of the story feels true. And so, the idea of being able to centralize two-factor seems great. It almost feels too good to be true, is perhaps where I'm at. I am putting on my tinfoil hat, and I'm saying, yeah, but oh man, security, though. And again, I will 100% defer to 1Password on this. They've thought about it. But it's mostly I want to get to the place where I understand the thought process that they went through to decide that this is perfectly fine because they definitely did that work. I'm certain of that. I just want to read a white paper or something, and I haven't found it yet. [laughs] I'm like, let me get to that deep place of trust because that's what I want to be at with security tooling and those sorts of things. STEPH: Yeah, I haven't looked for something like that, but that sounds...I'm kind of surprised that doesn't exist. CHRIS: Oh, it quite possibly exists. I haven't done much of a search, frankly, at all. Mostly, I'm in the space of like, huh, that's weird and then moving on with my day. Because there's not a lot of free time to go search for the white papers on the internet. But yeah, so moving from 1Password or LastPass or 1Password, or maybe I'll just end up with both for a while. I really hope I don't end up in that space, although you're describing it as a positive, so maybe I will. STEPH: I have found it helpful for me. When you find that white paper, because you are more likely the type of person to read that white paper than I am the type of person to read it, then I would love a summary. That would be much appreciated. CHRIS: I'm so intrigued by the persona that you're describing of me of; like, you're the kind of person who would read a white paper. I'm like, well, I don't know if that feels true or if it's definitely true or definitely not true. But if I do happen to find it, and especially if I happen to read it, [laughs], I will share it with you and perhaps with the listeners as well. Let's see, one other small thing. I have a bad idea. I don't want to share the bad idea with you. I want to more share it with the audience, and then I want the audience to tell me exactly how bad of an idea it is. STEPH: [laughs] CHRIS: Because I'm sure it's a bad idea. I'm just not sure how bad. STEPH: I love that there's not even a scale of goodness here. It's just nope, this is terrible, but I don't know how terrible it is. [laughs] CHRIS: What's fun is in the later parts of this episode, we're going to go into a segment of good idea, bad idea, sorry, good idea, terrible idea because I like that framing. No, this one is firmly bad idea, but how bad is the question. So we're working on the app, and we keep running into inconsistencies around symbols and strings. As any Rubyist who has worked in the language for any amount of time, especially in a Rails app, you have experienced this unpleasantness. There are strings; there are symbols. They're often used somewhat interchangeably, and yet they're different. You'll hit bugs. You'll hit edge cases. You'll hit nils that you didn't expect to be there because you tried to fetch a symbol. It, in fact, was a string, et cetera. So, what if we just applied HashWithIndifferentAccess everywhere, just deep in the internals of the app or in the Ruby runtime? What if we were to just turn this on? My sense is this would be terrible for performance reasons. My understanding is that's why symbols exist is because they are a more performant mechanism. Strings are complicated within the object model of Ruby because they're mutable. These are things that I understand very loosely, as you can tell by the tone of voice that I'm using. But symbols and strings they're separate. They're separate for reasons, performance I believe to be the main reason. But what if we were to just say, well, what if it could be like easy, though? That's what I want. Like, this is the promise of Ruby is that I want to express my code in a way that feels like the words I would use to describe to another human. That's the way I always think of Ruby is it's as close to the words I would use to describe the sort of business logic as possible. And yet these symbols versus strings thing it's just annoying, frankly. And again, I think very good reasons for it, I'm sure. But what if we were to just do the silly thing and turn on HashWithIndifferentAccess for everything? I don't even know that that's fundamentally possible. I don't know that there's the relevant hook or the way to do that. But I would love that because we're using it somewhat regularly throughout our app right now, where we're getting data from one API. And in our test suite, it's one way, and in our code, it's the other way. And granted, that speaks to us being inconsistent in our usage. But overall, I would just love for this to not be a thing. And so, how bad of an idea would it be? How much of a performance hit? That's my guess as to what it would be. Maybe there's actual fundamental correctness that would go wrong here. But my sense is by collapsing the space together; we would actually get more correct. I don't know. Anyway, how bad do you think of an idea this is? STEPH: I was thinking through some of the bugs that you're running into. And I think you provided some nice insight around that around it's the fact that you're fetching data from API. So it's typically you're parsing. That's how you're getting the string and symbol differences is because when you're parsing JSON and then you have a mixed case of maybe you have a symbol, maybe you have a string, or maybe you're parsing it differently. Are there other places in the application where that's a concern? CHRIS: I want to say one other place that we're running into it specifically is we're using a lot of enums, particularly ActiveRecord::PGEnum backed enums. So these are Postgres enums at the database level. And then, within our Rails models, we define them as enums. And the enum is typically defined within the model as a mapping of symbol to string. It could be symbol to symbol. I'm not even sure. I think this might be in terms of our implementation. But you say like, it's an enum. The key is foobar with an underscore, and it's a symbol, and then the value is foobar, but it's a string. And maybe both the key and the value could be symbols; maybe that's a thing, maybe this is our fault. But certain times, when you're interacting with the value, it's a symbol. Certain times I find it to be a string. I feel like that's true. I don't think I'm making that up. [laughs] It's possible I'm making it up. But that's another place where I feel that inconsistency or other values within the system that like as they go through certain type coercion layers, they'll start as a symbol, and then they get saved to the database, and then they get reflected back, and they come back as a string. And it's like, well, that's unfortunate. It was a symbol a minute ago, and now it's a string. And so our tests suddenly break in this way, or our code is inconsistent. And it's enough of a nuisance that I had the bad idea the other day. And so, I wanted to bring the bad idea to this space. STEPH: I think you're right. I think the main reasoning for not having everything just be strings is for looking for that performance benefit. And so then using that HashWithIndifferentAccess then you'd have to loop over everything and then convert it. So I imagine, like you said, there would be a performance hit there. I don't know how bad of an idea it would be. But when you said this, it brought up a memory because I remember someone proposing or the Ruby community talking about the fact, like, what if we didn't have strings? What if everything was just a symbol? Or can we just have one over the other? And there is a ruby-lang issue; it is 7792. And we shall also put it in the show notes and send it to you. [chuckles] And this person is proposing make symbols and strings the same thing. And then some people call out specifically the idea of using HashWithIndifferentAccess and saying, yes, that works wonderfully, but then you are going to have a performance hit for it. So it sounds exactly like everything you're saying. I don't know the outcome. I mean, clearly, the outcome is we're not there. But it seems like a really good place to see the reasoning or different approaches that maybe people have tried in this space. CHRIS: Ooh, I love that. I definitely want to read that and see what sort of deeper thinking folks have done on this. Because again, this feels like another one where definitely folks have thought about this, folks who know more about it and have chosen the current path that we're on for reasons. But I would be really intrigued if I could be like, yeah, I would just like it to be easy to start, and then have the performance optimization be something that I could opt into. Again, that's probably not tractable within the language. Like, oh, we have a hot code path here that we want to actually have immutable symbols only. And that's the sort of thing if we've done this HashWithIndifferentAccess everywhere, you can't back out of it. And so, therefore, you're stuck in a performance low point. That feels like a bad case. And so maybe that's the reason is like, you will shoot yourself in the foot with this definitely. But yeah, I'm intrigued. So I will definitely read what you're sharing here. And we'll include it in the show notes, of course. I'm probably not going to do this, just saying that out loud because it seems like a bad idea. I just want to know how bad of an idea. STEPH: I do love it, for when I'm building a class that's working specifically closely with an API, I do reach for HashWithIndifferentAccess frequently. Because like you said, I just don't want to worry about it. I want to set it up top. It's one of the rare times that I actually will use something in an initializer where I'm like, hey, pass in the data. I'm just going to run it through this method. And then all the data from here on forward you can access it in either way. So the class doesn't have to care; a tester doesn't have to care. So I do feel your pain, or I at least will always reach for it whenever I'm building a class specifically around interactions with JSON. CHRIS: So for a segment that I framed as how terrible of an idea this is, you're like, hmm, I don't know how terrible. That seems to be your take, which is interesting. STEPH: Good point. Let me assess for a moment. I'm going to go just from skimming this issue, although I think partially this issue is talking about the fact that if you merge symbols and strings, it's like, hey, friend, you're going to break a ton of stuff and break a bunch of libraries, and these two things do serve a purpose. So this may not be exactly what you're looking for, but it has some interesting conversation on there. But embedding it deep down in the app so that just happens naturally sounds like it's just a performance concern. So yeah, it comes down to what is the question? How big is the performance? So I feel like I can't say it's a terrible idea until I actually know what the performance hit is. CHRIS: So a plausible question. That's where we're going to put this in the category of. [laughter] STEPH: Plausibly terrible, but still worth researching. CHRIS: Not obviously not terrible. But anyway, these are some of the ideas at the top of my head right now. That's a rough summary of my week. Mid-roll Ad Hey, friends, let's take a quick break to hear from today's sponsor, New Relic. All right, so you've probably experienced this before where you're just starting to fall asleep, and it's a calm, code-free peaceful sleep, and then you're jolted awake by an emergency page. It's your night on call, and something is wrong. But I have some good news because you have New Relic, which means you can quickly run down the incident checklist and find that problem. So let's see, our real user monitoring metrics look good. And that's where New Relic measures the speed and performance of your end-users as they navigate the site. But it looks like there's an error in application performance monitoring. If we click on the error, we can find the deployment marker where it all began, roll back the change, and, ooh, problem is solved. We can go back to bed, back to sleep, and back to happy. That's the power of combining 16 different monitoring products into one platform. You can pinpoint issues down to the line of code so you know exactly why the problem happened and can resolve it quickly. That's why more than 14,000 other companies, including GitHub and Epic Games, use New Relic to improve their software. So you know that next late-night call is just waiting to happen, so get New Relic before it does. And you can get access to the whole New Relic platform and 100 gigabytes of data free forever. No credit card required. Sign up at newrelic.com/bikeshed. That's newrelic N-E-W-R-E-L-I-C .com/bikeshed, newrelic.com/bikeshed. STEPH: I have an update that I can share around factories because the last time we were chatting, I was sharing that strategy that we're pursuing where we're trying to minimize factories and then speed up the CI time by reducing the work that those factories are doing. So Joël Quenneville has done some phenomenal work and this past week, specifically improving factories. And he found one particular factory that he was digging into. So some stats before the change. The factory was taking around two seconds, which I know on paper doesn't sound so bad, but it gets more interesting. So total database time is around 1,000 milliseconds. And 833 total database queries were being made, which includes reads, creates, and updates. So then after, Joël was diving into this looking mainly to reduce the number of database queries because that's such a big number. So after the change, which took a lot of research on Joël's part, the factory is now taking around one second, so half of that time. The total database time is around 666 milliseconds. And the total database queries went from 833 down to 647, so a nice improvement there. But the real wonderful outcome of the story is not just those stats, but okay, so how did we impact CI? So we spent time working on this factory. And we have reduced, and we can see some of that in the stats. But how does that apply to the bigger picture? And so Joël took the time of the last 20 successful builds, and based on those builds, we average 27 minutes and 37 seconds for each build. With the factory change that he made, that same test suite was now averaging 21 minutes and 33 seconds. So shaved off six minutes from the build time, which is about a 22% decrease in the build time which is just fabulous. So that was a really nice win from all the work that had been invested in improving that one factory. CHRIS: That's a heck of a haircut there so glad to see that the efforts are paying off. STEPH: Yeah, it was a really nice win to see that we had researched which factories we should pursue, and then we were methodical about that. And then Joël worked hard to improve this factory and saw such a large payoff. It's one of those areas where the team has already invested a lot of effort and hours into improving the test suite. And it's challenging when you have so many areas that you'd like to improve and 100-plus engineers also contributing to that same codebase. So how do you improve and keep up with it all at once? They had spent about a year, so I think they were recognizing that yes, there are still a lot of areas to improve but also felt like small efforts wouldn't move the needle. So it was a nice data point to remind ourselves that we can still reduce the CI build time in a significant way. We just need to be very strategic about where we invest our time in those improvements. There is also an interesting conversation that Joël and I were having because we have a daily sync with each other each day. We've now been embedded with a team with a client, which is wonderful, but before then, we were also chatting with each other. And we like to chat about code, so we've had lots of fun conversations around code. And one, in particular, this week, came up about how people view code differently. And there's even a tweet that Joël shared that I can link to in the show notes. And there's one view that code is a liability, and if a line can't justify its existence, then it should be deleted. And then there's another view that code is an asset. If a line isn't causing any immediate issues, then why not keep it? And part of the reason that came up was while I was going through and reading pull requests, there was a particular change where someone was memoizing an expensive call, which was great, something that we wanted to do. But then they were also memoizing a very fast operation in two other places where it was just like parsing some params something that, you know, superfast and only getting called in maybe two places. And it was one of those that just caught my attention to be like, hey, I love that you memoized this other call, but this one, I don't think we need the additional overhead or complexity of adding memoization. And I found myself when I was writing that suggestion for the author that I was already looking for more than just to say, like, hey, this is more than we need. Because I've realized that often I take that stance of code is a liability. So if we don't need it, let's just get rid of it. But I've definitely run into other people where they're like, well, it's not hurting anything, so why can't I just leave it? And getting that kind of pushback on suggestions about removing code. So it was a fun opportunity to think through okay, well, why is this memoization not just unnecessary, but how could it actually cause us problems? And what's the cost of keeping it in, not just the cost of removing it but also the cost of keeping it in? And that was fun to talk about. CHRIS: I'm so glad you're bringing this particular conversation up because if we're being honest, I saw Joël tweeted about this. I saw it. I sent an email to myself linking to the tweet with the subject of the email being ahhhh, just A-H-H-H-H, which I believe was me being like, oh my God, we got to talk about this. I apparently didn't want to write all of those words, so I just wrote ahhhh. But as a handful of asides, one, if you're not following Joël Quenneville on Twitter, @joelquen, that is a mistake, because Joël is one of the clearest, most concise, and effective thinkers about code that I've ever seen. The writing that Joël produces is absolutely fantastic. And having worked with Joël for forever, I still will look at his Twitter feed and be like, well, this is fantastic. You're saying amazing things that I have not heard you say. So, again, strongest recommendation I can make; please follow Joël on Twitter and also via the Giant Robots blog and all of those other places. But in particular, I saw this one come through, and I was like, oh, man, we have to talk about this. So I actually have it up in my email app right now behind the scenes. [laughs] I was like, oh, I want to mention this to you, Steph. So I'm very excited that you're bringing it up in this moment. It is such an interesting thing. It's such an interesting case of like; I deeply believe both of these truths, and yet they do seem to be in contradiction. And so what do we do with that? More generally, I feel like that's true of a lot of stuff in life, like, the ability to hold two competing ideas in your head and be able to know where one applies and where one doesn't. That is a critical thing to get to in life and to figure out how to do, and that's some of the hard work of thinking. But in particular, this one, the idea that code is a liability. You have a line of code...I'm going to read it precisely as Joël wrote it, "Code is a liability. If a line can't justify its existence, it should be deleted. Code is an asset. If a line isn't causing any immediate issues, why not keep it?" And I think for me, if I were to try and interpret this, because I do believe both of those sides, I would apply one during code review. When code is coming into the application or when I'm writing code, do I need this? Do we need this? Is this necessary? Because it really should be necessary to come into the app. But then once something has made it in, especially the longer something's been in there, I think code sort of ages and matures. And so, the longer it's been part of the app and not causing an issue, the more I am liable to just leave it at rest. Just say, sure, or not at rest but as part of the runtime production code. But these are two competing ideas, but I think they apply at different times in the conversation. And so I'm definitely on memoization. In particular, memoization is a form of caching. Caching I have run into a handful of caching bugs in my life, let me tell you. I'll probably run into a few more. So if we can avoid caching, let's do that. So that's a particular question around that thing. But again, that idea of like the point in time to have that conversation is during code review or initial authoring or when it's about to come into the app. But if we've had some memoization in the app for forever and you're like, do we need this memoization? I don't know, but don't remove it because maybe it's very important at this point. Maybe it's one of the cornerstones holding up our application. So that's a bunch of thoughts about that. But also super glad that you brought this up because I was very excited about this particular tweet. STEPH: Yeah, there's someone that said something very similar to what you just said around they agree with number one for all new code. And they agree with number two, where code is an asset for refactoring. And I thought, yep, that's a great way to look at it. And I hadn't really thought about that specific perspective. And so it was one of those moments. Because I do like when people will push back on something that I so firmly believe on, not that this person did. I was, frankly, having a conversation with myself based on previous conversations with other pull requests authors that I've had that it's not related to this particular pull request. But in general, when people do push back on something that I do have such a firm belief in...and early eager optimization around memoization is something that I'm just like, I don't want to do it, especially for something that's so cheap and in such a fast execution and something that we're only calling twice. There's no benefit to it at that point. But then when someone says, "Well, but it's not hurting anything," then I appreciate that question because then it's more of not just pushback, but it's sort of well, tell me more. What is the pain that I'm introducing by keeping this in? And then that can be a really nice conversation to have with someone around; like you just said, I've seen caching bugs, and this could be a caching bug, and they are painful to then triage. And so we've introduced this optimization, but it's actually just going to cause us debugging pain later. And we really didn't even get the reward from it in the first place. So I really like those conversations when I feel like there's a little bit of a challenge of where I'm like, oh, I hold this as a deep truth, and somebody doesn't, and I would like to have that conversation with them. There are also some other fun conversations; one was around introducing a query object, which, as you know, we're both really big fans of. And then there was another great question because not everybody who works on this team is really familiar with Ruby and RSpec. They work in Scala, but then sometimes they hop over to the Ruby side. And so then they hop into the Ruby channels, and they're asking questions. And one of them was around the idea of introducing an RSpec Matcher. And they're like, "Am I doing this right? Is this how you would extract something to then improve your test? " And so that was a really fun conversation around like, yes, you did it right. This is exactly how you write a Matcher. But let's talk about use cases because extracting something to an RSpec Matcher to me means it meets the most generalized sense of usefulness that you want the whole team to use this and that you're willing to put in the extra overhead to then introduce this essentially like new RSpec DSL for the rest of the team to use and then maintain that. So it is the most aggressive step that I take when I'm trying to introduce a helpful tool. So then I shared my progression for when I'm extracting something for a test. And first, I will start with just a local method to that test because then it's scoped to just that test. And from there, then I will think about extracting to a shared helper. So maybe it's a module that can get included. But then its scope can still be confined to a couple of tests, but then we've also increased some of its observability. So then other developers will notice it and be able to share with it. And then from there, if I'm like, oh, this is super generic, it is testing time, and it's something that everybody is going to benefit from, then I reach for something like an RSpec Matcher or introducing a custom RSpec Matcher. So lots of fun testing conversations this week. CHRIS: That was a wonderful hierarchy. I like that a lot. I feel like that would make a good blog post. STEPH: There are some things that I realize that I just think of inherently about that I realize that would be fun to share. I'm much better at podcasting than I am at blog posting. [laughs] CHRIS: There's this friend I know, Joël Quenneville, very good at the blogging. He could probably help talk you through writing this up as a quick blog post. But you just described this heuristic hierarchy that you have. And you could probably provide quick examples of each, and I think encapsulate that knowledge. I, too, default to podcasting because it's easy for me to just say stuff here, and then it's there it is. But what you just said also mirrors exactly what I would think of as sort of the hierarchy and the reasons you're like, I'm not sure I'd go all the way to an RSpec Matcher. That hesitation is meaningful and comes from experience that you've had. And again, that seems sort of a trade-off of like, well, why not? Is it hurting anyone? What's the cost here? You know that cost. You have that in your head. And so now if you can capture...I don't want to put work on your plate. But I think that would be a great blog post. I would be happy to read that blog post and share it with other folks. STEPH: Cool, cool. Cool. So I totally hear you. So here's my hierarchy. Typically, I start with a podcast, and then I share it there. And then maybe it'll go to a tweet. And then once I'm like, okay, this is super generic, it can help everybody, then we've reached blog post status. CHRIS: I love how tweet is higher in the hierarchy than a podcast for you. That somehow the throw away let me just have 140 characters or 280, or whatever we're at these days, that somehow that's next in your hierarchy. But I agree; I share that place in the world. STEPH: Yeah, just writing is hard. Here I get to show up, and I say things. And then we have wonderful Mandy, who is then editing all of our words, so there's a safety net here. If it's just me and a keyboard, who knows what's going to happen? CHRIS: Then you'll probably think about the switches that you're using on the keyboard. And do you need a new keyboard? Should it be silent? What do we do? STEPH: I was thinking more how many exclamation marks do you use? That's always a question. CHRIS: Not too many, not too few. It's a difficult question. STEPH: [laughs] Mid-roll Ad Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code, so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: Pivoting just a bit, [laughs] what else is going on in your world? CHRIS: What else is going on in my world? So we are building out a whole platform over here at Sagewell, and one of the things that we need to build is a mobile app or, frankly, two mobile apps, one for iOS and one for Android. And I'll be honest; I resisted this for a while. I am a big, big believer in the web as a platform like deeply in my heart of hearts. That's the place that I want to spend my time. That's the thing that I believe in. And there are absolutely cases where truly native mobile apps shine, completely outshine what we can do on the web platform sometimes for reasons that are, I think, not great, limitations of the available mobile web platforms, et cetera, reasons that I'll slam my fist on the table or whatever it is. But there are plenty of really great mobile experiences, offline, et cetera, that we just can't...offline is not even a great example. See, I can't even find a great example. There are definitely things, though, where truly native mobile apps are 100% superior. But again, I'm such a big fan of the web platform that that's what I wanted to do. I wanted to hold on to this dream of, like, what if we just make a really great web app and it's just great? And then consistently, our backend is one singular thing. Our frontend is kind of one singular thing. And yeah, we got to deal with responsive design. But that's to me a much more tractable problem than fracturing our entire application architecture across a bunch of different platforms and having all of the logic of our domain splintered and especially depending on how you implement it. That's sort of a big question. I've talked a ton about Inertia.js on this podcast, and that's because I believe it's a really great example as to how to pull some of the logic back to the server-side, which, in my experience, that's where I want the logic to be implemented, our deep domain logic. I just want that to be on my server in a Rails controller, or a Rails model, or a command object, or any of those sorts of things, query objects, all of these wonderful things but server-side that's centralized in one space. Nonetheless, though, we had to build a mobile app. These are the truths of the world. Sometimes it just comes down to the expectation of your user base. And there are certain things that by building a mobile app we will get so, for instance, in our case, having biometric login, so fingerprint, or facial ID, or any of those sorts of things. Those are actually material security differences. They are actually, as far as I can tell, available on the web but not consistently on every browser, et cetera. So that's something that we can get by having our app as a native app. Push notifications is another one that certain platforms, certain web platforms have dragged their feet on, Apple Safari. iOS Safari, specifically, I'm looking at you, but that's an example of something that by going the truly native route, we'll get that. Similarly, access to some of the lower-level things, cameras, et cetera, that is something that we'll get a better experience of. And again, you can hear in my voice I don't want to really seed it to the native platform, but it is true right now, at a minimum. So we had a decision to make as to how we would implement these applications, and we went with an interesting route. So for anyone that's familiar with Turbolinks native, or I believe Turbo iOS is pretty similar. But I'm more familiar with Turbolinks native as there was a talk I Can't Believe It's Not Native I think is the name of the talk that was given a while back talking about the Turbolinks native architecture. So basically, what's happening under the hood is let's still render these things server-side. Let's send down some HTML. In our case, it's a weird sort of hybrid of HTML and not HTML. But broadly, let's say that the server is rendering things. And our native application is going to then be a native shell that wraps around WebViews. But it does so in not just a single WebView sort of way. It's instead trying to find that optimum hybrid spot where let's do native things where they make sense. So, for instance, we have introduced a tab bar at the bottom of our application that is a truly native UI. We similarly have push notifications, biometric login, et cetera. Those are features of the native platform that we're using. But then, for most of the screens, most of the screens that are just some text, maybe a button, maybe a form, et cetera, we are using the server-rendered code that we have. And so server-rendered, in our case, because we're Inertia, it's sort of a misnomer because technically it is being rendered on the client-side in the WebView. But, I don't know; we're now getting too nuanced and in the weeds for it. But what we've opted for is to reuse the same views, controllers, et cetera. All of that is still being reused. Our iOS and our Android codebase at this point are wrappers around those WebView stacks. So it's not just a singular WebView; it's a stack of WebViews. So if you're doing swipe to navigate thing on iOS, that'll work...or Android. I think Android has an actual back button, though, within the applications. But most importantly, we've introduced a tiny little bridge layer. So from our WebViews, we can communicate to the wrapping native context. And similarly, from our native context, we can send messages into our WebView. So we can have a button in our native UI. And when a user clicks that button, it will send a message to the WebView that it's wrapping around and vice versa. We can do push notifications. We can do all that sort of stuff. For any given view, like, say, the login view, we can say, "Hey, don't render the normal server-side thing. Instead, render this truly native, local Swift or Kotlin view that we want to use there." So it's an interesting choice. I think it's something that I've certainly seen applications that are just like, let's take some HTML and wrap it in a WebView, and it'll be fine. And they don't make great apps. But I think this time it might just be a good idea. I actually do think that the approach that we're taking, at a minimum, is buying us a ton of simplicity in terms of having to duplicate what are somewhat nascent domain concepts across multiple platforms. We're not entirely certain as to what our platform and what our business is going to be. So we'd love to non-enshrine that across three different platforms that are hard to update. Like the web, I can kind of change that every day. But iOS and Android because I have to go through review cycles, because I have to get them out to devices, because there are slow update cycles that individuals will use, I'm going to be stuck supporting whatever version of these applications are out there. And so if more of that is the dynamic content that's driven by the server, frankly, I just feel way better about that, at least for now, at least for the point in time that we're at. But I kind of believe that this may be a really useful architecture for us long term. That was a bunch of me rambling about the architecture. Let me pause there, thoughts, questions, comments, concerns? STEPH: First, I really appreciate the thoughtful approach and explanation. Also, you highlighted the reasons that y'all are pursuing having a native app, and all of that makes a lot of sense. Because there is that user expectation of you told me about a service that then there must be an app that I can download because that's what I'm accustomed to using versus having to go to a browser and then having to then remember the URL of the site that I'm supposed to go to. So there's that convenience factor. There's also the idea that some people go to the App Store and search for their solutions instead of going to a browser and searching for a service. So having that presence in the App Store can seem like a really huge win because then even if it maybe slowly pushes them back to use the website or as long as they get a decent experience, they've now at least been exposed to the idea of the service and that it's out there. But then, as you pointed out, building a mobile native application is a lot of work. And then it becomes a question of like, well, are you going to hire people to work specifically on these platforms? And then, is it really worth that investment at this point? Or is it worth the approach that you're taking where you're going the more hybrid approach? I am curious; maybe this is something that you'll know. So as you are investing in this hybrid approach and you are starting to collect more users that are then using the app versus going to the browser, then what does that pivot look like, or how does that further investment look like? If you realize that the UI isn't quite delivering the expectations that you want that if you'd actually built a native iOS or Android application, then what does that investment look like? Can you still reuse some of the work that you've done? Is it totally scrapping that work? I think that would be my biggest question around taking this first approach. Is it an all-in bet that we are now stuck to this? Or is there some salvageable pieces to then move this forward into native apps should we need to do that? CHRIS: That's a heck of a question. Have you made a terrible decision or just like an iffy decision? I think that the framework that we're choosing or, frankly, building right now will actually be amenable to a potential transition entirely into the native world in the future. So again, one of the options that we have here is the ability to say, no; this facet of the application is entirely native. We're going to opt-in. And so it actually happens at the navigation layer. So we can say, if a person transitions to the /user/signin route, instead of just rendering that WebView right in place, push a native Swift or Kotlin. Depending on the context that we're in or the platform that we're in, push the native view onto the stack and use that. And so we're able to, on a screen-by-screen basis, make a decision of no, we'd like to opt into native behavior here. And so, if we did eventually see that the vast majority of the users of the platform are using it via the native app, we should probably continue to invest in that and push in that direction. I think we could do it in sort of a gradual style, and that is critically important to me. I don't want to make a big bet and then be like, oh no, we got to rewrite from the ground up. And there's no way to do that incrementally. It's going to be a whiz-bang Friday launch that everyone's going to hate. That's the thing I want to avoid most in the world. And so I think what we found now is this seems great for right now because it allows us to avoid this complexity explosion of three different platforms and trying to keep them in sync and trying to keep them up to date. But it does, I think, give us an opportunity as we move forward to slowly sort of transition things over. We are, to state it, this isn't just like wrapping a WebView around things. We are building essentially a mini framework on both iOS and Android, or roughly Swift and Kotlin is what the actual languages are, to work with Inertia because inertia is the core technology that we're using. Inertia, thankfully, has a nice little event system in there, so we can say, Inertia on navigate. And when a navigate event happens, we can hook into that and then connect it to whatever Swift or Kotlin runtime that we're building here. And there are a couple of different events that we can opt into. And so that's giving us the hooks that we need in the current architecture. But longer-term, if we needed to, we could just, I think, slowly transition everything over to be truly native mobile, and then that would probably be backed by more traditional API endpoints and that sort of thing. I want to avoid that. That's my dream is to stay in this happy place where we're always going to need some web presence. And I would hate for those to be fractured distinct things. I've worked with enough mobile apps that are wonderful native experiences, and yet I'm like, could you just give me the desktop view? Just scaled to...like, I'll even pinch and zoom because you're hiding data from me, and that makes me very, very sad. Please give me the buttons, and the text, and the content that you would give me on the web. And the fact that you're not is just breaking my heart right now. And, frankly, for our user base, consistency of experience is something that I think is really important. So that's another facet of the conversation that is really interesting to me of like; I don't want it to be different on each platform. Certainly, a three-column layout doesn't work on an iOS app that is zoomed in 150%. But we can turn that into each column is just floated down and then otherwise have all the content in there. And I believe in that as sort of a fundamental truth of let's reshape the content but not fundamentally rethink it. I say that as something that I believed deeply. But as I said it out loud, I was like, yeah, but also, I don't know, make it work on the platform it's on. So I can see both sides. But I have had enough experiences personally where I'm sad about the app that I'm using. STEPH: Yeah, I could also see an argument for both ways where you don't want it to be fundamentally different, but then also, you want it to fit the platform. And then there may be some advantages to the fact that there is a different platform, and you want to utilize that. I also agree with the not hiding of the data. I have felt that pain where I have an app, but I really want to go to my desktop, and I really want to use it there. But then on mobile, it's then hiding, and I realize it's hiding. And that inconsistency really frustrates the heck out of me. So I can understand that as well. Overall, I really like this. You're taking a bet in a direction of we should have a mobile presence, and we should start attracting people through this new marketplace. But we want to reuse a lot of the logic that we already have before we go so far as then we're going to have to start building for each different platform. Because while I don't have a lot of experience in that area, the times that I have been part of teams that are building native apps, it's a big investment. I mean, they hire people very focused on that; designers have to design for browser, for mobile, and then for native, and then everything has to stay in sync across. You have to think about how a feature is going to work across all three of those different views. And so it is certainly not something to go into lightly, which I think is exactly what you're describing is that you're looking for that in-between to how can we start working our way in this direction but yet also do it in a way that we're reusing a lot of the work that we have versus having to invest full sail into then building out these different platforms? So I'm going to go with this is not a terrible idea. [chuckles] I'm excited to see how it feels once I can download this and check it out. I'm excited to then see how that feels from a UX perspective. But overall, everything you're saying really jives with me. It makes a lot of sense. I am curious, what about React Native? Is that something that you considered using? CHRIS: Oh yeah, great question and definitely something that we considered. We're not using React on the backend, so that was actually a consideration when I was thinking about Svelte initially is I assumed we'd be building a React Native app eventually for the native platforms. But I talked myself into Svelte for the web, and that is not the reason that we're not using React Native for the native apps. But it is an interesting sort of constellation of technologies that we have now. We're not using React Native because I'm clinging to this idea of what if we could have a singular experience? So React Native fundamentally you're building a native app that this is this bundle that you download that's got all of the UI and that front-end logic in that bundle that you download. And then when it wakes up, it makes some calls back to some APIs to get some data or to decide if I can do an action or to actually do an action, all those sorts of things. But you're building out a Rest or GraphQL or one of those APIs. And with my explorations of Inertia, I found that what if I didn't need to do that? What if I could do a more traditional Rails CRUD-like experience but CRUD in a good way (I mean it in the very positive sense of the familiar architecture) and still give users a delightful experience but not have to build a distinct API where all of the or majority of the logic was on our client-side? So if I did that, then my web client would need to be that much smarter. And each of the iOS and Android clients would need to be that much smarter because that's fundamentally how these technologies work. UI components they can give a higher fidelity experience, more native-like experience, but they tend to own a lot more of the smarts. And one of my core beliefs is however long I can get away with this, I want to keep as much intelligence on the server as possible and have my view layer be as minimal and as simple as possible. So I think React Native is a really fantastic technology for that sort of work. But my goal was to avoid that sort of work entirely. What if we had a singular way that we had the logic exist on the server-side, and then we rendered pretty minimal view layers? Or, from a user experience, the view should do all this stuff and show all of the things that they want. But I want that view layer to be as naive as possible. And by naive, I mean in the positive sense of like, I want to be able to change this very rapidly. I want to be able to evolve it and iterate it. And so this is more of a buy into I think the thing that Inertia gave me is valuable enough and if I can keep using that and reuse it, especially on these mobile platforms...now if we add a new fundamental part of our Sagewell platform, if we have that, it just exists on each of the iOS, the Android, and the web, and that's fantastic. And we're going to keep a really close eye on what experience that gives to the user. And is it still great? But presuming it is, the complexity savings there are so huge. Our team is a team of web developers that is able to think about things holistically and singularly. We implement it once within our stack, and it just works. And if we can do that, that is worth a ton. We may not be able to do that forever. But for now, especially while we're figuring things out, while we're super early on as a company, I think that savings and complexity is worth a lot. So it'll be interesting to see how it plays out, and will certainly report back. But I'm a big believer in this little adventure we're on. STEPH: Yeah, you said it perfectly there at the end; you're a team of web developers. And so as long as you can stick to that, then that's what's best for y'all and the team and the product. So that's wonderful. I have a short segue because I had a little bit of inspiration when we were talking about terrible ideas. I want to circle back to your other terrible idea because I have a terrible idea for your terrible idea about strings and symbols. Okay, so my terrible idea is you're talking about using HashWithIndifferentAccess for everything. What if you had a class or method that then will first try to access via string and if that fails, access via symbol, and then if that fails, then it fails loudly? So you now have this let's try this, and then let's try the next thing. I have strong feelings about this as I'm saying it. CHRIS: [laughs] STEPH: But we're in the terrible idea segment, so I'm going to embrace it. This is my terrible idea. CHRIS: HashWithIndifferentAccess with runtime exceptions. I think HashWithIndifferentAccess under the hood probably does what you're describing of, like checks one and then checks the other or checks has_key is probably the underlying implementation. I haven't actually looked at it. But some version of that makes sense. Falling back to the key error gets interesting. I did see a different thing recently of a deep fetch, which is something that I want, to stop trying to make fetch happen, except I'm going to try and make fetch happen. We thought about this a bunch where we have these objects that we need to traverse into. So we use dig to get into the third layer of the object, but dig doesn't care. And it's just going to happily nil out whatever. So I'm like, no, dig but then right at the end, fetch, deep fetch. I saw somebody post this recently. So deep fetch is something I want to make happen. HashWithIndifferentAccess, which raises at the end also intriguing. STEPH: So yes, but this will be a little different because this one, you don't have to do the transformation process upfront with HashWithIndifferentAccess where you have to pass the data first, and then it transforms it so then it can do these two different lookups or the fallback. This one, you're skipping the transformation process, and you're using your own custom method that then does that first check for a string or first check for a symbol and then default back to the other one and then fail loudly, yeah, if both of those fail. CHRIS: Interesting, and I have to see what it looks like in practice. But I mean, broadly, I'm into something in this space. Let us find some simplicity. That is what I want. STEPH: Let's find some terribleness and see which one feels not so terrible. [laughs] CHRIS: Some terrible simplicity. Well, I like that idea. We'll see where we get to with it. But I think on that note, and we've said a bunch of stuff today, should we wrap up? STEPH: Let's wrap up. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Logseq 是一款注重隐私（数据存储在本地）、开源的笔记工具。上手简单，又足够灵活，可以记录想法、笔记、管理 Todo 等等。我自己近一个月每天都用它来记录各种事项。这期节目有幸邀请到了 Logseq 的创造者秦天生（tiensonqin），来聊聊 Logseq 背后的故事和理念。 嘉宾：秦天生 主播：limboy, laike9m 时间线 00:56 - 01:18 天生的自我介绍 01:25 - 18:35 Logseq 是什么、创作初衷、核心特点和成长过程 没有满足需求的工具，就自己来写一个 投资人自己就是 Logseq 的用户，还会写插件 17:55 - 30:57 你自己是怎么使用 Logseq 的 团队内的协作，通过 Git ，把大家在做的事情、需要的帮助等整合到一个 Daily Page 中 也用过 Trello，但 Logseq 在串联上下文这块很方便，也方便 Weekly Review 时差和语言上的障碍需要克服 目前使用起来还不够方便，在开发多人协作的版本 使用标准格式的文件，方便数据的复用 Local First 是重要的考虑项 30:57 - 33:56 一天的时间是怎么分配的 早期大概一半时间开发，一半时间在社区，会跟用户视频。现在内部的协调会占用更多的时间 投资人因为也是重度用户，会提很多想法，甚至提供 UI/UX 优化文档 33:56 - 38:50 作为 Founder 最大的挑战是什么 在多语言，跨文化的背景下，如何让团队协作更高效 看清楚未来 插件很快就可以 GA 了（不需要再通过 Developer 模式开启） 38:50 - 42:05 从一开始就非常注重英文用户和海外市场，这个当时是怎么考虑的 比较自然的选择，开源吸引了很多英文用户，前同事也在加拿大，Discord 作为兴趣小组也挺成熟的 42:05 - 50:37 国内用户和国外用户使用习惯上的差异 差异不大，为中文用户提供了些便利（如输入两个中文方括号自动转换为英文） 部分用户会希望将其他 App 的功能嫁接过来，也会提不少想法，甚至提供文档对比不同 App 的交互细节 国外用户在录制介绍视频上很有一套，发完视频后有时会在 Discord 上 Cue 一下，问是否合适，非常客气 50:37 - 51:52 现在用英文沟通是否已经非常纯熟 聊产品、技术、理念这些问题不大，但生活化一些的俚语还差一些。 51:52 - 56:52 选择 Clojure / ClojureScript 的原因 一方面比较熟悉，另一方面也有不错的 dataScript 库可以用，函数式语言在数据操作方面会有些优势 56:52 - 64:18 选择相对小众的语言会不会有提高 Contributer 的门槛 会提高些门槛，但 Clojure 的学习成本其实也没有那么高，有几个贡献者就是周末花一两天看了下文档，然后就去修复 Bug 了 另一方面小众语言会吸引更优秀的人才 。（就像两人聊天，如果都看过神探夏洛克，这很正常，但如果都看过神探加杰特，这就有的聊了） 也有些用户因为 Logseq 使用的技术，而去了解相关的内容，如 dataScript / dataLog，因为要写 query。 应聘的人数还挺多的。招人会有许多渠道，如 v2ex, clojure 社区，Twitter 等等。对语言不做要求，但要有解决问题的能力 64:18 - 71:45 快速迭代过程中的一些痛点 目前测试还不够充分，对于出现过的 Bug 会优先补充测试，避免再次出现 对 Logseq 的愿景是信息的操作系统，目前虽然能够承载成千上万个 Markdown 文件，但对于想要达到的愿景来说还不够，所以在数据库的性能和扩展性就会有很高的要求。Rust 在数据库以及其他 CPU 密集的场景就比较有优势。 71:45 - 74:08 目前的人员配比对于重前端的业务会有影响么 目前团队最缺的是设计师和资深前端工程师 74:08 - 77:34 Logo 是什么含义，Logseq 的寓意 Logo 的含义一个是脚印，人生一些值得纪念的东西记录下来。还有就是一家人，知识的传承 Logseq 的取名主要是想找一个唯一的名字，搜索可以立即找到 77:34 - 83:13 做 Logseq 过程中一些印象深刻的事情 使用 Logseq 的用户分享的一些使用经历，如日本大学的一个教授在课堂上通过 Logseq 的幻灯片功能教学，一些学生也开始使用了起来 早期是通过 Github 来同步，对普通用户不太友好 Shopify 的 CEO 也是 Logseq 的用户，还写过插件 83:13 - 87:58 Stable 版本有计划什么时候放出来么 没有明确的时间点，先把 Bug 修了，已经构想了一些 Feature 待实现 迭代节奏上跟 Roam Research 的一些区别 87:58 - 89:08 Pro 版本的推出计划 Feature 上主要是文件同步和加密，以及协作上的一些增强 89:08 - 91:28 移动端的一些进度 Android 在内测了，iOS 版本顺利的话也很快可以内测了 手机端也是基于 WebView 来做 91:28 - 96:57 其他方面的规划 等多人协作功能出来后，把重心放在如何促进人学习和思考方面 把 Logseq 作为基建，在这之上构建知识库，形成学习社区 想做一个 GitHub 和 Wikipedia 的 2.0 版本 ShowNotes Logseq OrgMode Roam Research CRDT(Conflict-free Replicated Data Type) Solid Project RemNote 节目收听方式 除了 Apple Podcast 国区的各大泛用型播客平台 小宇宙 - ByteTalk 订阅 Feed URL 和不同的人聊天，会收获很多不同的东西，作为一个「老」程序员，我想跟不同领域的程序员们聊聊他们的故事、经历和感悟，或许也可以给正在收听的你一些启发。 欢迎在节目下方留言，如果你也有想聊的，可以邮件沟通：hi@limboy.me，一般会在两天内回复。

[קישור לקובץ mp3] האזנה נעימה ותודה רבה לעופר פורר על התמלול!שלום וברוכים הבאים לפודקאסט מספר 426 של רברס עם פלטפורמה - זהו באמפרס מספר 77 (!). התאריך היום הוא ה-16 בנובמבר 2021, ואנחנו כרגיל בבאמפרס עם דותן ואלון ורן - בוקר טוב.באמפרס זו סדרה של קצרצרים שבה אנחנו מכים [אבל בקטע טוב] בכל מיני חדשות, בלוגים ו-GitHub-ים מעניינים שצצו לאחרונה.(רן) אז אני אתחיל - אבל רגע לפני שאני מתחיל, רציתי לדבר על הכנס [!] שהולך ומתקרב - Reversim Summit 2021 הולך לקרות בסוף דצמבר, ב-26-27 בדצמברההרשמה ככל הנראה כבר פתוחה בזמן שאתם שומעים את הפרק [אכן) - אז אתם מוזמנים להירשם.חפשו Summit2021.Reversim.com או פשוט גגלו את זה ותמצאו את זה - מוזמנים להירשם!(אלון) ותוכלו גם לשמוע את דותן בכנס, אז בכלל שווה . . . .(דותן) איזה כנס?(רן) . . . דותן ידבר שם ואלון חלק מהצוות, אז כן - תיהיה לנו שם נוכחות.ועכשיו - לענייננו . . . .רן - הקצרצר הראשון שרציתי לדבר עליו - האמת היא שהרבה זמן לא הקלטנו, אז הצטבר לנו כאן חומר מאיזה חודשיים - לפני אולי חודשיים, או משהו כזה, נפטר אחד מ”אבות האומה” - Sir Clive Sinclair - נפטר בגיל מכובד, 81היה אחראי לכמה מהדברים המשמעותיים ביותר בעולם המחשוב, וכנראה הידוע ביותר מבין כולם זה בעצם המחשב הראשון שלי - ZX Spectrumעדיין יש לי אותו, דרך אגב - מקלדת מגומי, סימן כזה צבעוני של קשת בצד - למרות שאין לי את כל ההרחבות והייתי צריך לאלתר טייפ והייתי צריך לאלתר כל מיני דברים אחריםאבל המחשב עצמו עדיין קיים - לא בדקתי האם הוא עדיין עובד . . . אבל הוא לגבי קיים בצורה פיזית(דותן) לא, אתה לא יכול לעשות את זה . . . עכשיו אתה חייב לבדוק!לזכר! . . . אתה חייב לבדוק אם הוא עובד . . .(רן) אני רק צריך למצוא את הטרנספורמטור הנכון שלו . . . אני זוכר שהיה לו בלוק כזה שנורא היה מתחמם, כזה גדול . . . .(דותן) זה לא בעיה, זה אתה יכול לקחת כל . . . .היום יש לך כאלה מתכווננים, בטמבוריה הקרובה . . .(רן) כן - וצריך למצוא את החיבור טלויזיה . . . זה מתחבר ב-RF לטלויזיה, חיבור קואקסלי כזה . . . (דותן) זה גם פתיר . . . .(רן) פתיר . . . בקיצור, האדון זכה לתואר Sir בגלל ההמצאות שלו והתרומה המשמעותית שלו לטכנולוגיה.הוא לא המציא רק מחשבים - הוא גם המציא מכוניות והמציא כל מיני מכשירים חשמליים ואלקטרוניים אחרים, בנאדם באמת גאוןהוא המציא טלויזיית כיס, בגדול - שזה ממש מגניב, בשנות ה-70 כנראה שזה היה להיט.(דותן)הכיסים היו גדולים בשנות ה-70 . . . .(רן) לגמרי, כמו של הטלפונים של היום . . . .הבנאדם זכה לתהילת עולם כנראה בעקבות סדרת ה-ZX Spectrum שלו, שהיו לה כמה דגמים.רציתי להזכיר את זה שהוא לאחרונה נפטר, אבל אני חושב שהמקום שלו בהיסטוריה מובטח - יהי זכרו ברוך, ותודה על כל התרומה.הנושא הבא - פייסבוק מטא, שמעתם על זה? . . . . (אלון) פייסבוק מתה?(רן) אבל קצת לפני שהיא Meta, או יותר נכון - כפרומו לזה שהיא Meta, היא גם מתה . . .לפני משהו כמו חודש, אולי קצת יותר, היה Outage מאוד משמעותי ב-Facebook - והסיפור מאחוריו הוא מעניין, לכל הפחות.אז Facebook, קצת לפני שהיא שינתה את השם, למעשה היה להם Outage מאוד משמעותי של מספר שעות - אני לא זוכר אם שש או שמונה שעות - שבהן כל השירותים של Facebook היו למטה.עכשיו - מדובר על לא רק Facebook.com אלא גם WhatsApp ו-Instagram ואני לא זוכר מה עוד יש להם - והכל הכל היה למטה, וזה משהו שלא קורה הרבההיה זמן לצאת החוצה, לשחק . . . .אז הסיפור מאחורי זה הוא, כמו בהרבה מקרים כנראה, מתחיל מאיזושהי טעות אנוש - לא ניכנס לכל ה-Post-Mortem, רק נגיד ב-High-level - מדובר על איזושהי עבודת תשתית יחסית שגרתית שעשו ב-Data center, שבה החליפו תשתית של Fiber אם אני לא טועה וכדי לעשות את זה, היו צריכים להסיט את התנועה מרכיב אחד לרכיב אחר - ועושים את זה באמצעות פרוטוקול שנקרא BPG - זה פרוקטול שהראשי תיבות שלו הן Border Gateway Protocol זהו פרוטוקול שנועד לעשות את מה שנקרא “האמ-אמא של ה-Routing”, זאת אומרת - לתכנת, אם אני זוכר נכון מהשיעורי Networking שלי, את ה-Autonomous systems כדי שידעו אחת על השנייה ותדענה להעביר את ה-Traffic מאחת לשנייה - וזה משהו שרץ בעצם ב-Backbone של האינטרנט, BPG . . .עכשיו, Facebook, בגלל שהם כאלה גדולים, יש להם גם BPG משלהם [עם בלק ג'ק?] - כמו שיש כמובן גם ל-Google ואחריםבכל אופן, כדי לעשות את עבודת התשתית הזאת, אחד העובדים עשה Routing ובעצם תכנת מחדש את ה- BPG - ועשה שם טעות, ככל הנראה . . . והסיט למקום הלא נכוןוזה, בסופו של דבר, ברגע שזה קרה, למעשה זה יצר תקלה כל כך שורשית, כך שלתקן אותה - גם אם עלו מהר על השגיאה - כדי לתקן אותה היה צורך לנסוע פיזית ל-Data center, כי כל הרשת הייתה למטה, אז אי אפשר היה אפילו להתחבר מרחוק . . . .דווח גם שעובדים של Facebook לא יכלו להיכנס למשרד כי פשוט הקוראים של הכרטיסים [כרטיסי עובד] לא עבדו, כי הרשת הייתה למטה.(דותן) אה, את זה אני זוכר, עכשיו אני נזכר בזה . . .(רן) כן . . . היה צריך לנסוע ממש פיזית ל-Data Center כדי לתקן את זה סיפור שיכול לקרות לכל אחד - טוב שלא קרה לנו, אבל זה יכול . . . . אני מניח שטעויות מהסוג הזה יכולות לקרות לכל אחד, והמיטיגציה (Mitigation) של זה לא כל כך פשוטה . . .אני לא חושב שמדברים על מיטיגציה ב-Post-Mortem הזהאבל בכל אופן - זה בהחלט היה משהו שהורגש ונמשך הרבה מאוד זמן, ועשה גלים.ויכול להיות שזה היה רק הפרומו שלהם לשינוי השם של החברה - כמו שאמרנו, Facebook Meta, אבל אולי זה היה במקרה . . .(דותן) מה? זה מיטיגציה של “לחתוך את הפלומבות” . . . . מי שמכיר מהצבא(אלון) שמע, אחד הדברים המעניינים - זה על פי “מקורות זרים”, אני לא יודע אם זה נכון - בגלל שהם משתמשים רק בכלים פנימיים, אז אפילו לא היה להם Messenger לתקשורת, כדי לנהל את כל האירוע . . . .(דותן) זה לא “לפי מקורות זרים” - זה נכון, היום הכל נכון . . .(אלון) . . . ולפי השמועות הם התקשרו בטלפון, אתה מבין? התקשרו בטלפון! מה זה?! לאן הם התדרדרו? טלפון-כזה-לא-אינטרנטי . . . (רן) שיחת ועידה, כן . . . .מצד אחד - “Eat your own dog-food” זה נחמד, יש בזה הרבה דברים טובים; מצד שני - כשה-Backbone שלך נופל אז זו קטסטרופה, אין לך איך כלום.(דותן) בסדר, מה הסיכוי שזה יקרה? . . . (רן) כן, הא? אם זה קרה, זה לא יקרה שוב . . . בקיצור - בסופו של דבר יצאו מזה, מן הסתם - והחיים חזרו למסלולם.נושא הבא - בזמן האחרון אני מתעסק בתחום - או בעצם לומד - תחום שנקרא Reinforcement Learning, שזה תחום בלמידה חישובית שהוא, ככה, מעניין ונחמדונתקלתי באיזשהו Framework מאוד נחמד שהוציאו ב-Google שנקרא google-research/football ו-Google Research Football זו בעצם סביבת סימולציה של משחק כדורגל - שהיא לא פחות ממדהימה, לדעתי.בעצם, לקחו איזשהו Open-Source בסיסי של משחק כדורגל והוסיפו לו הרבה הרבה דברים מעל - תחשבו על FIFA, אבל FIFA שאפשר לתכנת . . . זאת אומרת שכל אחד מהשחקנים הוא בעצם סוכן עצמאי שאתם צריכים ללמד אותו איך להתנהג במשחק - איך לשחק, איך לשתף פעולה עם שחקנים אחרים . . . זה בעצם איזשהו Framework שבו אתם יכולים לבחון, בעיקר על אלגוריתמים בתחום של Reinforcement Learning - וה-Framework עצמו בנוי בצורה מאוד מאוד יפהלא יודע אם אתם זוכרים, אבל בעבר היו עושים הרבה מאוד מהבדיקות האלה מול משחקי Atari - למשל Pong וכאלה - היו מפתחים מעיין סוכן שיודע לשחק Pong בצורה שהיא “Super-Human”, זאת אומרת - יותר טוב מבני אדם.אבל כל ה-Benchmark-ים האלה של Atari הם כבר יחסית מיושנים, כי כבר כולם מצליחים - זאת אומרת, האלגוריתמים הלכו והשתפרו, וכבר בגדול האתגרים האלה כבר פחות ופחות מעניינים כי פשוט כולם פיצחו אותם.ועכשיו באו Google והוציאו לפני שנה או שנה וחצי את ה-Google Research Football - שזו סביבת Reinforcement Learning מאוד מאתגרת - וגם יפה.אתם פשוט יושבים וצופים במשחק כדורגל - וזה נראה טוב, זה ממש ממש נראה טוב, זה ממש נראה כמו FIFAיש גרפיקה מדהימה, יש מצלמה שזזה, יש את כל המסביב . . . זה פשוט כיף ללכת ולראות את זה ולשחק עם זה.ומעבר לזה - אפשר גם פשוט לשחק עם הכפתורים, זאת אומרת - אתם יכולים פשוט לקחת את המקלדת שלכם ולשחק נגד ה-Bots - בעצם נגד ה-Agent-ים שתכנתתם . . .זהו - סביבה מגניבה למי שמתעסק ב-Reinforcement Learning, אני מאוד נהנה לעבוד עם זה.(אלון) מגניב . . .(דותן) מגניב . . . מה עשית עם זה? נגיד, עכשיו בשביל המשחק, מה המטרה שלך? לפתח משהו שינצח אותך?(רן) אז בעצם המטרה שלי זה לאמן קבוצה - באופן אוטומטי, אני בעצם מייצר להם משתמש . . . בודק כל מיני אלגוריתמים של Reinforcement Learning, משתמש ב-Multi-Agentכי בעצם כל שחקן זה Agent נפרד, ואני צריך לגרום להם “לשתף פעולה”, צריך לגרום להם להצליח להבין מה בכלל צריך לעשות - ש”לבעוט לשער” זו “פעולה טובה”, ושכשליריב יש את כדור אז צריך לרוץ אחורה כדי לשמור על השער שלך - דברים בסיסיים כאלה [שכדאי ללמד גם הנבחרת האנושית שלנו . . .]אבל אחר כך צריך ללמד אותם לשתף פעולהבסופו של דבר, אני מייצר קבוצה - ומתחרה מול קבוצות אחרות(דותן) איך למשל אתה מלמד? מה זה אומר “ללמד”?(רן) בוא, אפשר לעשות קורס של ארבעה חודשים . . . . אבל בגדול, התחום של “למידה מתוך חיזוקים” זה אומר שאם עשית איזושהי פעולה, קיבלת איזשהו Reward מהסביבה . . . נגיד - בעטת את הכדור לכיוון השער ואז קיבלת Reward של 1 + . . .אז אתה לומד שהפעולה האחרונה הזאת שעשית - זו פעולה טובה. זה הבסיס של כל זה, ומזה אתה משליך אחורה.אז איך הגעת לפוזיציה שאתה באמת יכול לבעוט את הכדור לשער? אז גם על זה תקבל חיזוק, כי להגיע לפוזיציה זה טוב כמעט כמו לבעוט את הכדוראז זה כאילו ה-Basics של ה-Reinforcement Learning, אבל זה קצת יותר מורכב, כי יש פה עניין של מרחבים רציפים ו-Multi-Agent ודברים כאלהאבל זה הבסיס וזו סביבה מאוד כיפית לבוא ולפתח את זה כיפית אבל גם מאתגרת, זאת אומרת - יש כרגע תחרות ב-Kaggle ויש חוקרים שעובדים עליה - אני לא מכיר עבודה שמראה באמת קבוצת כדורגל מאוד טובה, ככה שזה מראה שזו באמת סביבת מחקר מאוד מאתגרת.(דותן) אז בעצם מה שאתה עושה זה שאתה הולך לשחק איתם כאילו?(רן) כן, אני בעצם מאמן קבוצה והולך לשחק מול קבוצות אחרות.(דותן) זה יכול לשרוף המון זמן . . . .(רן) כן, לגמרי . . .(דותן) כל פעם 90 דקות, לראות אם זה טוב? . . .. (רן) לא, זה לא 90 דקות - משחקים קצרים, זה מערכות קצרות - נגיד, עד שהכדור מגיע לשער זו מערכה אחת, עד שיש גול או חוץ זו מערכה . . . זה לא 90 דקות.(דותן) זה היה הרבה יותר מצחיק אם זה כן היה 90 דקות - אם היית חייב 90 דקות . . . (רן) כן . . . .אני כרגע מחמם GPU ב-AWS כדי שהדברים האלה יעבדו.(דותן) מגניב(אלון) זה באמת מגניב . . . מתי הגמר?(רן) יש Deadline בדצמבר . . . . אז בטוח יהיה הגמר.טוב - ומכאן מעבור אליך, אלון . . . (אלון) אלי?! טוב, וואו, כמה אני מתרגש . . . אלון - אז ניקח כמה דברים - אחד קליל ממש, אפילו לקצרצרים הוא קליל - GitHub עשו שאלה ב-Twitter, סקר - האם אתם אוהבים לעבוד עם מוסיקה? אם כן - תנו את ה-Playlist . . .ואז יש שרשור ארוך של Playlist-ים שאנשים שומעים מוסיקה איתם(רן) האמת שאני נסיתי כמה מהם . . . אני גם ראיתי וניסיתי כמה מהם - וכולם הפריעו לי להתרכז . . . [זה כי בטח ניסית את ה-Playlist רוק כבד נורדי של בר-זיק . . .]אתה עובד עם מוסיקה, אלון?(אלון) כן . . . יש לי כל מיני מוסיקות שונות לדברים שונים . . . . יש קטע שאתה צריך לחשוב קצת, יש קטע . . . [שאתה צריך לנסוע למצפה רמון?](רן) מוסיקה ל-Code Review זה Rage against the Machine?(אלון) ל-Code Review צריך פשוט “יאללה, הכל חרא, עזבו - תכתבו חדש . . . ” - בדרך כלל לא צריך מוסיקה, זה נורא מהר ה-PR . . . “אה, שום דבר פה לא טוב - תכתוב שוב ותחזור אלי”בפעם שלישית אתה מתחיל לקרוא - זו השיטה ל-PR טוב . . .טוב, עוד משהו קטן, למי שרוצה - אתם מקבלים קיצור דרך bit.ly או tinyurl או כאלה, ואתם רוצים לדעת לאן הוא הולך?אז יש שיטה מאוד פשוטה - ב-bit.ly אתם מוסיפים “+”, ב-cutt.ly אתם מוסיפים “@”, ב-tiny.cc זה עם “=” וב-tinyurl.com אתם מוסיפים “preview.” לפניבקיצור - אם אתם מקבלים bit.ly ורוצים לדעת לאן הוא הולך, אז אפשר לדעת, ממש חביב וחמוד.(רן) אתה מתכוון - לראות את ה-URL עצמו, בלי להגיע אליו, זה מה שאתה מתכוון? כי אם אתה לוחץ ,אתה מגיע אליו . . .(אלון) כן, אבל אם שולחים לך איזו פרסומת ואתה לא יודע מה זה, ואתה אומר “מי זה? מי שלח?” . . . (דותן) . . . אז אתה שולח לחבר ואומר לו “תלחץ, תגיד לי מה יש שם” . . . (רן) . . . . “שלח לי צילום מסך” . . .(אלון) את זה אני בדרך כלל לא עושה . . . אבל אתה לא פותח את ההודעות! אתה תמיד עושה לי “מה אתה רוצה?” . . . .(רן) זה כמו שהיה פעם “הטועם של המלך”, נכון? (אלון) נכון, עכשיו זה “ה-DevOps של המלך” . . . אז Cloudflare יצאו בהכרזה על משהו שנקרא R2 - זה “Rapid and Reliable Object Storage” וזה כמו S3 - אבל כמו שהם אומרים, זה “minus the egress fees” . . .מה שמעניין בזה זה שאני חושב שהדבר הזה יכול להיות די מהפכה בעתיד - כי יש להם את כל ה-”Functional edge” או “Workers on edge”, אני לא זוכר את המינוח המדויק שלהם [Workers], שזה תכל'ס “Lambda on Edge” . . . . כל מה שיש להם זה Edge.ואז יש לך גישה גם לקבצים האלה.אז אפשר ממש להרים אתרים ולעשות דברים מאוד מעניינים “בלי כלום”, רק על Cloudflare - וזה צריך להיות סופר-זול וסופר-מהירואפשר לעשות עם זה דברים מעניינים, כמו לשמור קבצים, ואז לפתוח אותם, Database-ים מבוזרים שעובדים על קבצים . . . . אפשר לעשות מלא דברים . . .(רן) אני מסכים, זה נראה לי משהו מאוד משמעותי . . . רק להסביר - כשהם אומרים “Object Storage, minus the egress fees” הם עושים רפרנס - רוב ספקי הענן - יש להם Object Storage, דהיינו - S3 והדומים של GCP ושל Azureהעלות של ה-Storage שם היא לא זולה - אבל מה שבאמת יקר זה ה-Outbound traffic, זאת אומרת - להוריד משם אובייקטים.אז לעשות Serving לאתר זה יכול להיות יקראם אתם רוצים להעביר את הדאטה שלכם החוצה, להעתיק אותו החוצה למקום אחר - זה מאוד מאוד יקרוזה סוג של Locking שיש להרבה מאוד עננים - זה זול להכניס, זה מאוד יקר להוציא את הדאטה . . . אז ה-”egress fees” זה למעשה הסכום שאתה משלם כדי להוציא דאטה החוצה מה-Sotrage על הענןאז Cloudflare טוענים שה-egress fees הולכים להיות - מה? אפסיים? או נמוכים?(אלון) הם טוענים “Zero” . . . שזה מעניין(אלון) וזה S3 Compatible - זאת אומרת שבתיאוריה, ברגע ש . . . אפשר “עכשיו” להתחיל לעבוד עם זה, כל מי שעובד עם S3, בלי לשנות כלום.אז זה ממש ממש מענייןגם מבחינת זה שזה יכול להוריד את כל העלויות של ה-Storageוגם שאפשר לעשות על זה אפליקציות מעניינות - בגלל ה-Worker-ים שיש להםאז בעצם הם יצרו פה Ecosystem מעניין ל-Cloud שהוא Serverless בצורה אחרת קצת - ובטח בעתיד הם יוסיפו עוד . . .(דותן) אני ממש בספק שזה . . . אני בספק אמיתי שזה אפס . . . . כי אם זה ככה, זה יכול לשנות הרבה תעשיות . . .הרבה מכל העולם של Streaming ו-Video ו-Encoding וכאלה - הרבה מזה מבוסס על היוקר של הדאטה שיוצאאני חושב תוך כדי שאני מדבר - אני ממש בספק שזה אפס . . . (אלון) הם טוענים שזה אפס . . . בגלל זה אני גם טוען שזה Game-changer. אני חושב שזה ממש ישנה את התעשיות ואני חושב שברגע שזה יתפוס - אם זה יתפוס, ואין סיבה שלא, בתיאוריהזו גם חברה טובה מאוד . . .(דותן) ברור . . . אני חושב שיש גם Buisness-ים שכרגע מוכרים שירות מסויים ומאפטמים (Optimize) את ה . . . הם משלמים על ה-Trafficהחוצה ואתה משלם כי אתה עושה Subscribe ל-Business שלהם - עכשיו הם יקבלו את זה באפס . . . זה אומר שיש להם יותר רווח, אז נראה לי שהם מיד יעברו לשם.(אלון) כן - וזה כנראה יגרום לספקי הענן הקיימים גם לעשות משהו, אולי AWS יוציאו את S4 . . .(דותן) מעניין, צריך לבדוק את זה טוב . . .(אלון) בקיצור - זה נראה סופר-מעניין, במיוחד . . . (רן) ומה הם אומרים על רפליקציה (Replication) נגיד? כאילו, יש להם הרבה דברים ב-Edge, אבל אם אני רוצה את זה עכשיו זמין בכל המקומות, אז איך זה הולך לעבוד? מעניין . . . אני רוצה את זה זמין באסיה, באירופה, בישראל . . . - ובכל אחד מהם יש להם כנראה גם הרבה . . .(אלון) בעיקרון אתה לא שולט על זה, והם אמורים לנהל לך את זה לבד עם ה-CDN-ים שלהםהרי זה מה שהם עושים - הם CDN . . . אז כאילו By default זה כבר “בכל מקום”איך הם עושים את זה בפועל? זו שאלה מאוד מעניינת, כי זה נורא יקר, מה שהם בעצם מתיימרים לעשות פה - גם תשמור בחינם, גם נביא לך את זה בכל מקום . . . (רן) טוב, גם הפרסום שלהם נחמד - הם כאילו אומרים ש-R2 זה אומר כל מיני דברים - למשל - Ridiculously Reliable . . . . זו אחת מהמשמעויות של R2 - הם אומרים שהם מספקים 9 תשיעיות [כתוב 11] - 99.999999999, ככה תשע פעמים - אחוז Reliability שזה משהו שהוא un-heard of למיטב ידיעתי . . . (אלון) זה eleven 9's . . . (רן) נכון! 11 תשיעיות . . . אני לא מכיר כזה . . . (אלון) תעשה עוד פעם! - 9-9-9-9- . . . (רן) ספור לי . . . כן, לגמרי מעניין(דותן) אני מהמר שהחוצה, לאינטרנט, זה עדיין עולה כסף, אבל אולי עדיין יש שם משהו . . . .כאילו יש איזשהו egress שהוא פנימי, אני לא יודע . . . . אבל צריך לקרוא את המאמר שהם מתייחסים אליו(אלון) בכל מקרה - סופר-מעניין, במיוחד כשה-Database-ים חדשים, בגלל שהם נהיים ענקיים אז הם עובדים בצורה מבוזרת - אז בתיאוריה, אפשר להחזיק ככה Database-ים מסויימים, ואולי זה יגרום לשיטה שונה של לכתוב דברים.בקיצור - Stay Tuned! R2 . . . . תעקבו.ולנושא פחות מרגש - Kafka UIלמי שיש לו Kafka - אז זה Kafka UI, אפשר לנסותלא בדקתי - תבדקועל אחריותכם - זה Open source, תמיד צריך להיות קצת זהירים עם Open source, אבל חוץ מזה נראה פרויקט מאוד יפה ומשעשעלמי שיש לו Kafka - קל לראות Partition-ים, Topic-ים, מה קורה, מה רץ…למי שרוצה קצת ויזואליזציה (Visualization) ולצאת קצת מה-Shell - נראה מאוד חביב וחמוד(רן) יפה . . . יש כמה כאלה, זה לא היחיד, אבל לפחות ויזואלית הוא נראה נחמד, לא יודע לגבי שאר הדברים . . . (דותן) אפשר אולי לראות, להשוות, לנסות . . . (אלון) אפשר להשוות, אפשר לבדוק - לקרוא . . . תסתכלו, תחשבו לפני שאתם משתמשים . . .בסדר, נמשיך הלאה . . .יש פרויקט שנקרא “K - שמונה - Sandra” . . . זה K8ssandraזה כאילו Kubernetes - Cassandra . . . זה בעצם Install של Apache Cassandra על Kubernetesאז מי שרוצה Cassandra ורוצה להריץ את זה על Kubernetes - אז יש עכשיו דרך נוחה לעשות את זה.עכשיו אני - יש לי טראומות וצלקות מ-Cassandra אז . . . (דותן) יש עוד שכבה שאפילו הופכת את זה לעוד יותר קשה! - “Kubernetes שרץ על . . . .”(רן) רציתי להגיד !Raspberry Pi, אבל Cassandra . . .. כאילו - Cassandra שרץ על Kubernetes על Raspberry Pi . . . נשמע לי להיט. וכל זה ב-Edge?(דותן) . . . מחובר לגנרטור . . . (אלון) בקיצור - לי יש קצת צלקות מ-Cassandra, לא על Kubernetes, ויש לי צלקות מ-Kubernetes, אז אולי ביחד זה יאזן אחד את השני . . . אבל אם מישהו בעניין של Cassandra, יש לו משהו - הייתי ממש שמח לדעת איך זה עובד, הדבר הזה . . .(אלון) הבא בתור - יש את ערוץ ה-YouTube של אבישי איש-שלום - זה 15m ops breakזה בעצם סרטונים קצרים של 15 דקות, לפי הכותרת שהוא אומר - בפועל, יש כאלה שהם קצת יותר, 17 דקות אפילו מצאתי . . . הוא לוקח דברים מהטרמינל ופשוט לוקח איזשהו נושא ומפרק אותו - Deamon-ים, DNS-ים, Executables וכל מיני דברים . . .לכל מי שרוצה 15 דקות של למידה טובה, חמודה - יש פה ערוץ עם 17 Video-יםמשעשע, קליל ואחלה הפסקה בשביל ללמוד משהו חדש. מומלץ בחום!(רן) תודה אבישי!(אלון) תודה אבישי . . . תעשה לי קוד . . .בוא נמשיך . . . Chrome DevTools הוציאו Copy CSS styles as JavaScriptשזה נחמד - אם אתם רואים עכשי איזשהו אלמנט עם CSS, אז אפשר עכשיו לעשות לו Copy as JavaScript . . .להעתיק את זה ל . . . Style as JS ויכולים להעביר את זה ל-React או לכל המקומות האחרים שלכם, וקצת משתלטים על הקוד במקום אחד, במקום להעביר את זה ידנית כמו שקורה הרבה פעמיםכשמתחילים לסדר את זה ואז אומרים “טוב, בואו נעתיק את ה-Style-ים” . . .אז פתרו לנו את הבעיה.זהו, אולי הגיע הזמן לחשוף את ה . . .(דותן) אותי זה ירשים כשיהיה Copy as JavaScript as CSS . . . אז זה באמת יהיה מרשים.(אלון) אותי זה ירשים כשלא נעבוד עם JavaScript, אבל עד לשם הדרך עוד ארוכה . . . שיהיה לנו Built-in TypeScript, זה יותר משעשע . . . בסדר, כל עוד זה לא Python אנחנו בסדר.זהו . . . (רן) דותן - אליך . . . דותן - טוב, אז נתחיל ב-Breach! - ה-Twitch Breachזה היה לנו, לא זוכר בדיוק מתי, בסביבות אוקטובר-כזה, היה Breach ב-Twitchאחד הדברים המדהימים שהיו שם זה שההאקרים גנבו את כל ה-Source-code בחברה . . . וגם קצת מידע פיננסי.ה-Package עצמו שקל משהו כמו 125Gb - שזה כנראה המון-המון קוד, במיוחד שזה בטח מכווץ.אני חושב שזה נפתח למשהו כמו 1Tb של קוד.זה היה ה-Breach . . . עכשיו, לאורך הדרך התפרסמו כל מיני תמונות מתוך הקוד, תמונות מזעזעות, אפשר לומר . . . בעיקר התפרסם הקוד עצמו - היה אפשר להוריד אותו ולראות מה יש בפנים.הקוד היה ברמה די מפחידה - סיסמאות בתוך הקוד, מלא קוד PHP, מלא פרטי Database ב-Production, מה שאתם לא רוצים . . . .מיד אח”כ הייתה איזו נפילה קטנה - שזה כנראה Hacker-ים שהם ככה, ניסו “לשחק במערכת” ולראות לאן זה מוביל אותם . . . מסוג הדברים שאני באופן אישי טוען שאנחנו עוד נראה הרבה מזה - כי ממש קשה להבין מה ההשלכות של 125Gb של קוד שדלפו החוצה . . .בדרך כלל ההאקרים מחכים לזה - בודקים את הקוד, בודקים איפה יש חולשות שקשה לראות מבחוץ - וכמו כל גנב מפעם - ברגע שקורה כזה משהו אז הם יושבים על זה, מחכים איזה חצי שנה - שנה ואז עושים את המכה.צריך ללמוד שלפעמים Breach כזה לא מיד מביא נזק - בדרך כלל אנשים חכמים נותנים את הנזק חצי שנה אחריאחרי שכולם שוכחים, אולי אנשי ה-Security התחלפו ועזבו ונכנסו אנשים חדשים - כל מיני דברים כאלה.(רן) אתה אומר שבעקבות דבר כזה, יש סיכוי טוב שכמה אנשי Security הלכו שם . . . .נזכיר ש-Twitch זו פלטרפורמת Streaming - התחילה במקור כ-Streaming של משחקים אבל היום זה Streaming של הרבה מאוד דבריםאחת הגדולות, אולי הכי גדולה בעולם - ובבעלות Amazon, נכון להיום, ככה שזה לא איזה סתם משהו קיקיוני.(רן) אבל דותן - אתה קצת חקרת את הפירצה הזאת. איך היא קרתה? זאת אומרת, דלף קוד ואולי עוד כמה דברים דלפו - אבל מה? איך פרצו?(דותן) אז לא באמת יודעים איך בדיוק זה קרה . . . יודעים מה המניע, לפחות מה שפורסם.באותו רגע שזה קרה, הייתי יחסית על זה ובעצם הסתובבתי בכל ה-4Chan - למי שמכיר, 4Chan [אתם לא בהכרח רוצים לעקוב אחרי הלינק, אולי לשלוח לאלון קודם שיבדוק …] ]זה איזשהו איזור נידח של האינטרנט עם כל מיני פורומים ואנשים פרסמו את ה-Breach ופרסמו פרטים - ומיד מחקו להם - ושוב פרסמו פרטים ושוב מיד מחקו להםאז אם אתה על ה-refresh אז אתה מבין איך זה קרה . . . .המוטיבציה הייתה בעצם הקנייה של Amazon - בואו נעשה “פריצה לגוף המרושע הזה”, במרכאות, שקנה את החברה.ובואו נעשה Shaming, בואו נביא את ה-Data של כל האנשים וכמה הם מרוויחים - וניצור תכך כזה בין כל ה-Network הזה - זו הייתה המוטיבציה.איך זה קרה? לא ממש פורסם . . . זה כזה גדול עד שלא פרסמו את הממצאים.(רן) בסדר, אוקיי . . . .(דותן) אני מניח שאם בכלל אז עוד שנה כזה, עוד חצי שנה.(אלון) עוד חצי שנה זה כבר לפריצה הבאה, לפי מה שאתה אומר . . . (דותן) לגמרי . . . אבל אני כן אגיד שהדברים האלה הם . . . שאלו אותי, למשל, האם אפשר לעצור את הדליפה של החומרים האלה - והתשובה היא “לא” . . . .לא משנה מי “יחתוך את הרשת”, הדבר הזה כבר ב-Torrent-ים ומי שרוצה יכול למצואאפילו לא צריך את הקובץ עצמו - את ה-Magnet Link וזהו: יושבים על 125Gb, באינטרנט של היום אז זה תוך כמה ימים עד שבוע כבר יש לכם את כל הקוד שלהם . . . זו הרמה.עכשיו אתם פותחים את הקוד - 125Gb זה המון . . . מה שנקרא “לכל מקום שתזרקו את האבן תפגעו במשהו מעניין” . . . כמובן שאל תעשו את זה - לא לנסות בבית . . . אבל אם מישהו היה רוצה, ככה הוא היה עושה…(אלון) אני רוצה להגיד שהיה להם נזק ישיר מזה כבר, כי היו סיסמאות ל-Database והם פרסמו דברים מה-Database, כמו כמה מרוויחים שם השחקנים, ה-Streamer-ים - וזה יצר קצת בלגן עם החברות האחרות, עם YouTube וכאלה . . .(דותן) כן, זה פשוט מאוד מאסיבי . . . . הכל שם, ממש הכל שם, זה סופר-מאסיביאני מעריך שזה יהיה פי כמה וכמה יותר גדול ממה שראינו עד עכשיו, פשוט Common Sense.זהו, אז נעבור קצת לדברים יותר אופטימיים - למי שרוצה לצייר Chart-ים, Candlestick Charts, שמאוד נפוצים בעולם ה-ForeX - בטרמינל . . . . - יכול! יש ספריית Rust שעושה את זה[זה cli-candlestick-chart]אם לא שמתם לב - נכנסתי כבר ל-Thread של ה-Rust, אז אתם מוזמנים להתחיל לצחוק עלי על הזמני קימפול (Compile), ולשאול כמה זמן לוקח לזה להתקמפל וכל מיני דברים כאלה . . . . תרגישו חופשי להפריע לי . . .(אלון) אנחנו נצחק עליך בסוף - אנחנו עדיין מקמפלים את הבדיחה . . .[1-0 לאלון . . . ](דותן) אה, אחלה . . . אז זו ספרייה ממש מגניבה -אני פריק של - נראה לי שאני אומר את זה באופן קבוע - של גרפיקה ב-Terminal, אז זה תמיד מרשים אותי ונחמד.האייטם הבא - יש ספרייה - יותר טכנולוגיה - ש-Google פיתחה - זה נקרא scudoו-scudo זה Allocator שהוא נקרא-לזה-מוקשח . . . . כש-Allocator זו החתיכה - אם נדבר רגע Low-level - זו החתיכה שעושה את האלוקציה של הזכרון (Memory Allocation)אפשר להשתמש בה אם אתם עובדים עם C ו-++C, מחברים ל-Allocatorתמיד למערכת ההפעלה יש את ה-Allocator שלה - אבל יש כל מיני Allocator-ים אלטרנטיבייםאלו לא דברים שאנחנו נחשפים אליהם כשאנחנו עובדים ב-High-level, ב-Python ו-Node וכאלהאבל כשאתה עובד יחסית יותר Low-Level, אז אתה יכול להשתעשע עם Allocator-ים אחרים - עם Tradeoff-ים של Performance ו-Security וכו'.אז זה באמת אחד כזה - שהוא הרבה יותר Secured ואין לו שום tradeoff - הם אומרים שהוא . . . העניין פה הוא Performance כמובןהם אומרים שהוא “מספיק מהיר” או “מהיר כמו” ה-Allocator-ים האחריםאז אם אתם עובדים עם Rust ובא לכם להחליף Allocator, שזה דבר שהוא שורת קוד אחת - שזה מדהים - אפשר לעבוד עם ה-Allocator של Google, החדש.הוא יותר מוקשח ואין סיבה שלא - לפחות ככה Google אומרים . . . אז זה מעניין.הפרוייקט הבא, בהקשר של S3 וכאלה . . . .(רן) שנייה, דותן - אני יכול לשאול כמה שאלות לגבי ה-Allocator הזה? . . . .(דותן) בטח . . .(רן) כתוב שהוא יותר . .. אמרת “מוקשח”, פה הם מתרגמים את זה ל”הוא יכול להגן נגד heap-based buffer overflow ו- use after free, ו-double free - איך הדברים האלה בכלל קורים ב-Rust? ב-Rust עצמה, ה-Compiler לא אמור להגן עליך מפני זה?אז זה שייך לאיזור שנקרא Unsafe . . . כמו לכל דבר, יש שכבה מסויימת ב-Rust שהיא Unsafe . . . (רן) הבנתי - רק אם אתה עובד ב-Unsafe, אתה צריך את השמירה הזאת - אם אתה עובד ב-Safe . . . (דותן) כן, אבל הדבר הזה שייך לעולם הזה - זה פשוט רכיב שהוא Low-level - וכמו כל דבר, אתה, “בחיים השוטפים שלך”, לא באמת שם לב ל-Allocator, זה כאילו סוג של פעולה של . . . “בא לך להחליף Allocator” זה לא משהו שאתה עושה כל יום…אם אתה בונה פרוייקטים שדורשים Tradeoff-ים מסויימים, כמו יותר Security או יותר Performance וכו', אז אתה יכול להתנסות עם להחליף Allocator-יםשזה - מניסיון - עושה הבדל.אני החלפתי Allocator אצלנו בפרויקט, Allocator שנקרא jemalloc, שנחשב הרבה יותר מהיר - וראיתי את ההבדל בעיניים, אז . . . זה מגניבוכמובן - שום דבר בקוד לא השתנה.זהו, אז האייטם הבא - נקרא kamu - וזה בעצם סוג של “Git ל-Data”זה פרוייקט שבנוי ב-Rust, כמו הרבה פרויקטים בעולם ה-Data ב-Rust שמתחילים.יש משהו מאוד מפתה: Performance ו-zero overhead - כמובן שזה מאוד מפתה ומזמין לבנות פרויקטים ל-Data ב-Rust - והרבה דברים כאלה מתחילים.אז זה עכשיו התחיל, יחסית עכשיו - והוא רוצה לעשות Git מעל Data - שזה אחלהיש גם כמה דברים כאלה, נדמה לי שהם באיזור - למשל dbt - שזה פרויקט מסחרי, וזה מגניב.כמו כל פרויקט כזה, יש לך דיאגרמות של ארכיטקטורה ואיך זה עובד והכל מאוד מאוד פתוח ומאוד מזמין.אני לא יודע אם זה יפגוש את הסוף - יש לא מעט פרויקטים ב-Rust שמתחילים מאוד hardcore ונגמרים עם “אוקיי, משכתבים מחדש” - אבל בדרך יש המון המון למידה וידע - אז זה אחד כזה.מן הסתם לא נראה לי [שכדאי] להשתמש ב-Production, אבל כן אפשר ללמוד ולראות איך הם בונים דברים.(אלון) יש צמיחה של פרויקטים מהסוג הזה . . . . של “Git over S3” וכאלה . . . (דותן) נכון, אני חושב שזה התחיל ב-Reproducibility- זה היה “איך אני עכשיו לוקח דאטה שלי, שמאמן מודל בגרסא אחת - ואחרי זה אני מתקדם, יש לי עוד סט של דאטה שמאמן מודל בגרסא 2 - איך אני יודע לחזור למודל מספר 1, ולעשות Reproduce לבאגים של Machine Learning?” . . . . זה היה, למיטב זכרוני, ההתחלה של זהואחרי זה, זה הלך גם לרמת התשתיות - “בואו ניקח את כל הדבר הזה, ובמקום לעשות Hard Thinking לגרסאות מסויימות של דאטה, בואו ניצור “סוג-של-Git” מעל דאטה, מעל S3, לא משנה מעל מה.אבל היופי פה הוא מן הסתם המאסות האדירות של הדאטה ואיך עושים Versioning לזה.(אלון) מגניב . . . ועכשיו עם R2 זה גם חינם!(דותן) נכון - אבל ה-Storage הוא לא חינם ב-R2 . . . זה עדיין לא בוננזה(אלון) לא נורא(דותן) האייטם הבא - מה שנקרא “אחד משלנו”: אורי, שעובד אצלנו פרסם מאמר ב-Towards Data Science - הוא עובד הרבה על לייצר Data-set-ים ל-Source Code כדי ללמוד מהםוהוא נתן פה את רשימת ה-Pitfalls וה-Do - Don't Do שלוקליל, מעניין - למי שמתעסק בלמידה מעל קוד זה, שווה מאוד לקרוא.(רן) אתה מתכוון ל”לג'נרט (Generate) קוד כדי לעשות למידת-מכונה על הקוד”?(דותן) כן - אז אנחנו עושים למידה שהיא דומה למה שראינו ב-Copilot - רק שהתחלנו עם להבין שאחד האתגרים זה copyrights וקוד מסווג - וגם תוצאות מסוכנות כשאתה לומד בצורה עיוורת . . . .ככה התחלנו מההתחלה, שמנו את זה על ה . . . .(רן) משתמשים ב-Copilot?(דותן) לא . . אנחנו בנינו משהו . . .(רן) לא . . . אני שואל אתכם, באופן אישי - אלון, דותן - אתם משתמשים עכשיו ב-Copilot? אני משתמש . . . .(דותן) לא, אני לא צריך . . . . לא צריך Copilot . . . (רן) ברור, לא צריך . . . . אבל . . .(דותן) אני יודע לבד . . . (רן) אני התחלתי להשתמש לפני איזה שבועיים, וזה כאילו - לפעמים זה מדהים ולפעמים זה מעצבן, אני חייב להגיד.רק אני אזכיר - Copilot למי שלא זוכר [397 Bumpers 69], זה כלי שנותן לכם השלמות קוד אוטומטיות, אבל הוא עושה את זה על בסיס GPT3, זאת אומרת שהוא עושה את זה בצורה אינטליגנטית, על בסיס של Data set שנלמד מתוך הרבה מאוד פרויקטים ב-GitHub - ויש Extensions, נגיד ב-VSCode, ואתם יכולים פשוט להשתמש בזה - וזה ייתן לכם Code Completionעכשיו - זה לא “סתם Code Completion” - זה כותב לכם שורות שלמות, פונקציות שלמות לפעמיםאתם מתחילים לכתוב את הפונקציה והוא “מנחש” את ההמשך, ואתם יכולים לקבל או לא לקבל את זה.אז אני משתמש בזה כמה זמן . . .אז לפעמים ההצעות הן כאילו “בול מה שאני צריך”, וזה מדהים - ולפעמים זה ממש מעצבן, עד כדי שזה “ממש דומה אבל יש שם באג” . . . נגיד - באג שאולי גם אני הייתי פעם עושה, ועכשיו כש”הוא” הציע לי את זה אז לא שמתי לב, ואז אני מסתכל על לאט ואומר “וואלה, האינדקס פה לא נכון, בעצם היה צריך אינדקס אחר”, וכאילו . . . (דותן) . . . ואז הזמן שחסכת הלך לאיבוד . . .(רן) . . . כן . . . .אז אני מאוד נזהר עם לקבל את ההצעות שלו - ועדיין אני כל פעם מסתכל וחושב “וואו, זה מדהים”.זה נחמד לראות את הדברים האלה קורים.(אלון) מה אכפת לך שיש באגים? זה באגים של מישהו אחר . .. .(דותן) נכון . . . אתה כל היום מתקן באגים של אנשים אחרים, ושוב פעם ושוב פעם . . . תחשוב שאתה תיקנת, אז גם מישהו אחר קיבל את אותה הצעה - וגם הוא תיקן . . . זה כמו זמן שנשרף על . . . .היה אז את הפרויקט של SETI, זוכרים? של המחקרים על סיגנלים מהחלל, ולנסות לגלות יישות אינטליגנטית, כשכל מחשב קיבל איזה Chunk וככה בזבז CPU וחשמל? . . . .אז יכול להיות שזה כזה - מלא אנשים מתקנים בו זמנית את אותו באג . . .בקיצור, אז זהו . . .(אלון) נשמע כמו ביטקוין . . . כולם מנסים לחצוב באותו זמן את אותו ה . . .(דותן) לגמרי, כן . . . זו הגרסה היותר מאוזנת של זה . . . זהו, מאמר נחמד- למי שמתעסק - שווה לקרוא.עוד דבר מדהים שיצא דווקא השבוע - ב-Rust יש . . . . אין Static Analyzer מכיוון של טעויות אבטחה וטעויות נפוצות - יש כמו Linter כזה, כמו Clipy, שהוא מדהים ישבה אוניברסיטה ופיתחו כזה, בעצם משימה אקדמית כזאת - GIT, ה-Georgia Institute of Technology - ופיתחו כלי שנקרא Rudra, שזה Static Analyzer ל-Rustעיקר הפוקוס שלהם - דיברנו קצת על ה-Unsafe, דרך שימוש ב-Unsafe, אם כבר מפתח הלך לשם, לאיזור הזה, המסוכן - בו ננתח את הקוד שלו ונעזור לו לא לעשות טעויות.מה שמדהים פה הוא שהפרויקט האקדמי הזה ניתן לשימוש מיד - אז ב-Rust יש מנהל, Package Manager שנקרא Cargo - פשוט עושים Cargo Install Rudra, ואז Cargo Rudra ונגמר הסיפור, אתם בעצם משתמשים בפרויקט האקדמי.בהרבה פעמים, החווייה שלי זה שפרויקטים כאלה נשארים ב-Level האקדמי - כותבים את המאמר, מפבלשים (Publish) אותו וסיימו עם זהאבל פה יש משהו שהוא מאוד שמיש, והקהילה משתמשת בזה ונהנית מזה - שזו סימביוזה מדהימה בין אקדמיה לקהילה.נושא קצת אחר - התעסקתי לא מזמן עם Sandboxing של של Process-ים במערכות הפעלה - איך לוקחים Process ועושים לו הגבלות למינהן, אנחנו מכירים את זה מהעולם של Docker.בתוך Docker יש כל מיני הגבלות לכל מיני Process-יםוגיליתי משהו מאוד נחמד - ל-Mac יש . . .איך נקרא לזה? “תוכנה” או “כלי”, שבא עם ה-Mac, שנקרא sandbox-execהוא כבר Deprecated - זה כנראה מסוג הכלים האלה, שהוא “דלת אחורית” כזאת, שלא הרבה משתמשים בהן - וניתן לייצר איתו Sandboxing למה שבא לכם.אתם יכולים לקחת כל אפליקציה ולכפות על האפליקציה לא להשתמש ב-Network, להשתמש רק בקבצים מסויימים, לא לגשת לנתיבים מסויימים וכל מיני דברים כאלה מעניינים.כותבים את ההגבלות ב-Lisp או ב-Sicp - שזה גם מאוד אנושי ומפתיע ומזמין . . .ואפשר להשתמש בזה כבר עכשיו מה שעוד מצאתי - ושמתי לינק, או שאני אוסיף - זה שיש אנשים שפותחים Github Repo עם כל מיני תוכניות פופלאריות ב-Mac וההגבלות החכמות אליהןלמשל - אם יש לכם Chrome, אין לו שום סיבה לגעת לכם ב-Folder של אפליקציות . . . אין שום סיבה כזאת.או בספריות של Settings בתוך ה-Home שלכם - כל מיני דברים כאלה שכשחושבים על זה אז זה מאוד Makes sense שזה אפילו יבוא מהיצרןכי בסופו של דבר, אם יש איזשהו Extension ככה “מלוכלך” ב-Chrome - ואם Chrome לא מגביל אותו אז אף אחד לא יגביל אותוזה נכון לכל אפליקציה שאתם מורידים - וזה סופר-מגניב, ברגע שגיליתי את זה.(רן) למרות שתראה - בעולם האפליקציות, ה-Mobile Applications, הולכים על “Whitelist” [או allowlist] - ופה מדובר על הגישה של blacklist [או blocklist] - “תגיד מה אתה לא מרשה”הגישה הבטוחה יותר מכיוון Secuiory זו גישת whitelist [allowlist] - שזה משהו שמקובל בעולם האפליקציות - אמנם הרזולוציה היא לא כזאת גבוהה, אתה לא אומר כל Folder אלה רק נותן . . . יש איזשהו Set סגור של הרשאות כמו האם אפשר לגשת ל-GPS או אפשר לגשת למצלמה וכו'.אבל זה משהו שמקובל בעולם ה-Mobile - וזה נחמד שיהיה את זה גם . . . .(דותן) נכון, אין ספק שיש פה Glitch די גדול - שמערכות הפעלה הן - איך נקרא לזה? lagging behind the . . . (רן) . . . קצת פחות בטוחות, כן.(דותן) בדיוק - למרות שב-Mac קצת הוסיפו את זה: היום אפליקציות מבקשות ממך לגשת ל-Downloads ודברים כאלה, שזה מנומס וסופר-נכוןאבל יש כל מיני נתיבים אחרים - אני מוריד כלי פיתוח, או כל דבר שאני רוצה סתם לשחק איתו - ולא תמיד זה קורה.בקיצור - כלי ממש מגניבהוא Deprecated - המחשבה מאחורי ה-Deprecation לא ברורה, אבל די ברור שה-Core Library שזה משתמש בו - שזה דומה, נגיד, ל-Jails במערכות הפעלה אחרות - זה משהו שנולד כדי להישאר, ו-Mac בעצמו, ה-OS 6 בעצמו משתמש בזה.זהו, האייטם הבא - בכל שפה חדשה שנולדת, יבוא מישהו ויממש את כל האלגוריתמים - מ-Cormen או ממקומות כאלה - ועכשיו עשו את זה ב-Rust, שזה עוד Milestone נחמד מאודלמי שרוצה לראות איך ממשים אלגוריתמים נפוצים - כל מיני Sort-ים, Graph Algorithems וכאלהבעיקר זה נותן, הייתי אומר, “מבט אינטואיטיבי לאיך שנראית שפה” - למי שעשה [למד] מדעי המחשבכל אחד שעשה את זה יודע, פחות או יותר, בראש שלו - יש לו כבר “צלקת” של איך שנראה Buuble Sort או Quick Sortואז אפשר לבוא ולראות את זה בצורה ברורה בשפה אחרת שהוא לא מכיר - וזה נחמד לתרגם את זה, מחשבתית.(אלון) נחמד . . . (דותן) כן . . .האייטם הבא הוא הרבה יותר “מרעיש”, הייתי אומר - יש פה פרויקט שנקרא tauri, וזה סוג של תחליף ל-Electronלמי שלא מכיר - Electron Apps, אז אני אמנה כמה, אני אנסה מהזיכרון . . . אז אני עובד עם Figma שלדעתי זה Electron [יאפ]. . . עם מה אתם עובדים, שהוא Electron וטוחן לכם את הזיכרון והמחשב? . . . (אלון) VSCode . . . (דותן) אני חושב שגם Slack . . .(רן) VSCode אני חושב שכבר לא Electron, אני חושב שהם עשו את זה מחדש . . . אבל הוא היה Electron בהתחלה ... (אלון) אה, נכון, Atom היה Electron . . . ו-WhatsApp . . . (דותן) WhatsApp . . . כל העטיפות ה-Native-יות הן בעצם . . . Electron, הסיבה שהפסקתי לעבוד עם זה זה שפשוט יש לי מלא Electron Apps במקביל ואז זה גומר לי את המחשב . . .אני מעדיף לעבוד כבר ב-Chrome - ש-Chrome ינהל את המשאבים שלו וככה אני מנסה To hack it.וגם כל אפליקצית Electron זה לפחות 50-60Mb, מכווץ - 130Mb פתוחפה, המהפכה היא שזה משתמש ב-Rust - הפתעה! - אבל זה יוצא 5Mb . . . וזה משוגע.והיופי פה זה שכמובן - מה ה-tradeoff? איך זה יכול להיות?אז זה משתמש, ב-Default, ב-WebView של מערכת ההפעלה - ואת כל הפערים ש-Electron מפצה עליהם הם פשוט עשו ב-Rust . . . אז זה סופר-מגניב, אני מניח שזה בא עם קצת מגבלות ודברים שאי אפשר לעשותאבל חשבו פה ממש על המון . . . Self-updater, להתחבר לנוטיפיקציות (Notifications) של המערכת הפעלה, כמובן Cross-מערכות הפעלה - Mac, Linux, Windowsממש . . .(אלון) רגע, זה HTML? כאילו . . . . זה Web לכל דבר?(דותן) כן, WebView, תעשה מה שבא לך . . . אני . . .(אלון) למה זה לא בעצם דפדפן? . . . אם אתה אומר שהוא יותר מהיר, הוא ב-Rust . . .(דותן) קודם כל, ב-Electron נולדו גם כל מיני דפדפנים חדשיםאני זוכר את ה . . . לא זוכר איך קוראים לדפדפן של ה-Privacy שנולד, עם הלוגו של האריה [Brave?] . . . . לא זוכר אותו בדיוק, אבל נולדו כאלה, בדיוק אחר כךואז, אתה יודע . . . בסופו של דבר, אנשים מעדיפים להשתמש ב-Chrome.אבל כן . . . וגם WebView הוא לא באמת כל היכולות של דפדפן מלא. אני מניח שמישהו יבוא ויממש מעל זה משהו דומה.זהו, סופר-מרגש - ואלטרנטיבה ממש-ממש טובה לאפליקציות, כי אצלי לפחות “העצם בגרון” זה הגודל של ה-Electron Apps שנולדו.(רן) תגיד, אתה - יש לך עוד משהו על Rust? יש לך עוד משהו ב-Rust?(דותן) כן, במקרה, ממש שמח שאתה שואל . . . . האייטם הבא זה gituiלמי שכל הזמן מחפש Git UIs, אני חייב להגיד, באמת מחווייה אישית, שיש מלא Git UIs בחוץ - וכולם מאכזבים בכל מיני צורות . . . אני לא יודע במה אתם משתמשים ומה עובד לכם, אם בכלל.לפעמים יש לי Chain Set-ים רגישים וגדולים שאני אומר שאני חייב שנייה מבט על - מה קרה פה? וגם שנמשכים על הרבה זמןאין הרבה כאלה, אבל לפעמים יש.אז אני מעדיף שנייה להסתכל ויזואלית (Visual) על מה שקרה ולברור את השינויים - ולפעמים אני צריך Git UI כלשהו . . .(רן) אני לא משתמש . . . אני, האמת, לא משתמש ב-UI, כאילו - ניסיתי פה ושם את Tig ו-Git Tower ועוד כל מיני דברים כאלה - אבל לא, אני תכל'ס משתמש ב-CLI כל הזמן.(אלון) אני משתמש עם ה . . .(דותן) גם אני משתמש רוב הזמן עם ה-CLI, אבל לפעמים אתה רוצה שנייה להיות מאוד מאוד זהיר, זה המתי שאני כן צריך את המבט-על.(אלון) אני - צוחקים ע ישב-Git אני Junior, אני עובד עם UI . . . אבל יש את ה-GitHub Desktop, שהוא חביב, ויש את זה שהיה טוב אבל תמיד טחן את ה-CPU, אז אולי הם סידרו את זה - ה-Sourcetree של Atlasian.הוא היה טוב - אבל זה היה כבד, כאילו אתה מרים מערכת הפעלה ומשגר טילים לחלל [כבר היו מקרים] . . .כולה, וואלה - Viewer על Git, למה טחנתם לי ארבעה Core-ים במקביל? אבל אולי הם סידרו את זה כבר . . .(דותן) כן - אז פה יש אלטרנטיבה שהיא אותו דבר, רק על הטרמינליש כמה כאלההיתרון של זה זה שהוא כתוב ב-Rust והוא מהיר וקליל.זהו - זה זה.יש עוד כמה אייטמים - אז אחד מהם זה applied-ml - יכול להיות שזה כבר היה פה [?]אבל זה ככה קפץ לי תוך כדי חיפושים - ומה שאהבתי פה זה שכל המאמרים הם לכיוון של Apllied, פחות תיאורטיים ויותר “איך עשינו בחברה כזאת וכזאת”והרבה פה, בסופו של דבר, זה לינקים לבלוגים ו-YouTube Vidoes של כל מיני חברות שמראות איך הן עשו משהו.הרבה פעמים זה מאוד פרקטי - והחלק השני של זה זה שהם מפרסמים גם את המחקר והכלאבל זה תמיד בא מהפרקטי.יש פה Reading List משוגע, סופר מענייןאני עשיתי לזה סוג של Bookmark, כדי כל הזמן לחזור ל-Reading List הזה.(אלון) שמע, זה מגניב לאללה . . . . יש פה כל מיני דברים מגניבים(דותן) כן, זה כייפי כזה, כאילו . . . קריאה לפני השינה(רן) אוסף של הרבה מאוד Case-Studies או בלוג-פוסטים על Machine Learning ב-Production מכל מני סוגיםאם זה מערכות המלצה, רגרסיות, Computer Vision - בקיצור, מה שלא תרצה . . .(אלון) זה לא רק Machine Learning . . .(רן) אוקיי . . . Applied ML . . . יש פה גם דברים של Data Engineering והכל, אבל בגדול הפוקוס הוא על Machine LEarning, לפי השם . . .(דותן) כנראה, ניתן Preview - יש פה Driving Shopping Upsells from Pinterest Search שפורסם ע”י Pinterest Engineeringואחרי זה Bringing Personalized Search to Etsy שפורסם ע”י Etsy Engineering . . . זה הסטייל, כאילו . . . בלוגים כאלה, מעניינים(אלון) כן, אבל יש פה דברים שזה לא Machine Learning . . . מי שנתן את הכותרת התחיל עם Machine Learning ובסוף דחפו לו שם דברים שהוא לא שם לב . . . (דותן) אז תזהרו מה-”לא-Machine Learning”, שלא תפלו באיזה מאמר על נגיד אופטימיזציה של Search . . .(אלון) חלילה! יש פה מאמר על Analytics at Netflix: Who We Are and What We Do - שזה לא נראה לי בכלל על . . . טפו! זה בכלל לא קשור ל-Machine Learning . . . (דותן) ה-Data Scientist שקורא את זה אחר כך צריך חמש פעמים לטעון דאטה ל-Pandas ולשרוף . . .(אלון) איזור שלם על Team structure . . . באמת, אנליסטי, דאטה . . . מי שמתעסק עם Machine Learning - קחו מפתח שישב לידכם כשאתם עוברים על ה . . . .(דותן) לפתוח Issues . . . (אלון) קחו מפתח לידכם, שיגיד לכם איזו שורה לקרוא ואיזו לא - שחלילה לא תכנסו לחומר לא קשור . . .(דותן) לא קשור, לא כשר . . . טוב, האייטם הבא - האמת שתפסתי את הראש . . . זה התחיל ב” . . . What the” כזה ואז עוד יותר ועוד יותר ועוד יותר . . . זה בעצם פרויקט של GTA III - למי ששיחק בילדותו - וזה כנראה בנאדם שאמר “אני רוצה לעשות לזה Reverse engineering, לבנות את המשחק מחדש - בלי שיש לי את ה-Source Code בכלל” . . . .והצטרפו אליו, בתקופה של הקורונה, מלא מפתחים - ועשו את זה . . . הרבה עשו Reverse Engineering ל-GTA III . . . .זה לא חוקי, אני חושב - והמשחק עובד . . . בלי שיש להם את השורות קודוהסיפור המדהים - זה לקח לי זמן לעכל את זה, כי זה כל כך מדהים שאמרתי “זה משוגע” - זה שהוא התחיל . . . הוא כאילו פתח פרויקט, ואז היו לו DLL-ים ... אם אתה לוקח את המשחק עצמו, אז יש לך DLL-ים - ה-DLL-ים בדרך כלל חושפים API פומבית לצורך המשחק עצמו - ואז הוא הסתכל, עשה Listing של ה-API הפרטי והפומבי, והתחיל לקורא ל-DLL-ים האלה, בלי שהוא חבר, שזה סוג של משוגע . . . ואז, אחרי הרבה עבודה, הוא הבין שהוא סיים משהו כמו . . . הוא כל הזמן העריך את זה - 10,000 שורות קוד, עשה להן Reverse Engineering - ונשארו לו רק עוד 200,000 . . . אחרי הרבה מאמץ.ואז הצטרפו אליו המון אנשים, בגלל הקורונה, והם עשו את זה . .. אין לי מושג אפילו איך להתחיל להבין את ה-Magnitude של הפרויקט הזה, אבל זה משוגע, באמת.(רן) אז הפרויקט עצמו הוא ב-C, ברובו - למרות שאני רואה שיש גם קצת ב-Assembly . . .(דותן) ++C, כן (רן) אוקיי . . . דרך אגב, הוא Archived, אז יכול להיות שיש כאן איזשהו עניין חוקי . . . אז עשו לו Archive, אבל עדיין אפשר לגשת אליו, כל הקוד זמין, רק שאי אפשר לשלוח אליו Pull-Request-ים יותר. . .(דותן) כן, כאילו - אם הייתי החברה שפיתחה את GTA - זה Rock Star Studios? אני לא זוכר כבר - הייתי כזה אומר לו “טוב, התקבלת . . .”(רן) וזה גם בית ספר טוב ל-++C . . .(דותן) . . . “בוא, קח פרויקט . . .” - יותר מזה? אין יותר מבחן או ראיון מזה . . . “תשכתב את כל המשחק מאפס, בלי שאתה יודע את הקוד שלו . . .”(רן) . . . “נאבד לנו ה-Source Code, אתה יכול לעזור לנו שנייה?”(דותן) אז זה התרגיל הבא - אם יש לכם חברה ואתם מגייסים אנשים: התרגיל למפתחים הוא “תשכתבו את כל הטכנולוגיה של החברה, יש לכם שנתיים לעשות את זה” . . .(אלון) זה אחלה תרגיל - אנחנו עושים אותי כמובן, מה זאת אומרת? . . .. אבל אצלך הוא לא היה עובר, כי הוא לא כתוב ב-Rust . . .(דותן) הייתי משתמש ב-Copilot . . . היה כותב לי את הכל.(אלון) יכול להיות שזה מה שהוא עשה . . . כתב “GTA Source Code” ובום! - ה-Copilot נתן לו הכל . . .(דותן) יש מצב . . . בקיצור, אפשר לפתוח לו Issues . . . אפשר לפתוח לו Pull-Request-ים, אני רואה . . . בואו נחטט ב-Closed, נראה מה הוא סגר . . . .(רן) רגע, אז מה זה אומר שעושים Archive? אם הפרויקט Archived אז מה זה אומר?(דותן) אה . . . מכריזים ש”סגרנו” . . . שלט על החנות של “נסגר, תודה רבה, הייתם אחלה” . . .(רן) לא, אבל כתוב Read Only . . . אתה אולי יכול לשלוח לו Pull-Request-ים, אבל הוא לא יקבל אותם כי הפרויקט הוא Read-Only, לפי מה שכתוב.(דותן) יכול להיות, כן . . .זהו - ואפשר להוריד את זה, אני רואה . . . אפשר להוריד את כל ה-Source Code, אז . . . .בקיצור - למי שאוהב את הדברים האלה, זה מעניין.זהו, אייטם אחרון - זה נקרא system-design-primer זה אייטם שנתקלתי בו המון - אני חושב שלפני כמה שנים אפילו ככה נגענו בו - אבל הוא כל הזמן מתעדכן, כי Design של מערכות צריך אבולוציה, וזה לא אותו הדבר.זה אחלה לחזור לבקר - אם אתם רוצים להיזכר איך לתכנן מערכות - מה הכללי אצבע וכל מיני Designs של מערכות נפוצותנגיד, יש פה תרגילים כמו “תכנן Web Crawler” ו”תכנן Key-Value store” וכל מיני כאלהזה, ככה - נחמד כזה, מחליף סודוקו . . .(רן) אז זה כאילו סוג של הכנה לראיון עבודה בנושא של System Design, או יותר מזה?(דותן) זה יותר “רענון מחשבתי” . . . כמובן שאפשר להתשמש בזה לראיונות עבודה, אבל א. אפשר כן לקרוא וככה ללמודב. אפשר ליצור מתוך זה תרגילים לראיונות עבודהאבל בשבילי זה יותר כזה Refresh נחמד, קריאה קלילה ומרעננת . . .(אלון) שמע, יש פה דברים שאם אתה ממש חופר לעומק, אתה תגיע ממש רחוק ב-Rabbit Holeכי אם אתה הולך על Database-ים פה, באיזור של ה-No-SQL - אז יש לך ממש את ה-Paper-ים של Bigtable ו-Cassandra, אז זה הולך רחוק . . . .(דותן) פעם היה קטע . . . מה זה “פעם”? היה לפני 11 שנה כזה, 2010 - היה קטע שהיית נרשם למגזין

Starring:k_katsumi, sonson_twit, d_date, kateinoigakukun 新iPad mini，新MacBook Proの良さ，Apple Care高杉，Xcode Cloudのバッドノウハウについて話しました． 1. iPad miniきた 2. MacBookProきた 3. evil apple care, 高すぎる 4. 損保ジャパンのスマホ保険　https://www.mysurance.co.jp/service/sumaho-hoken/ 5. Apple Care https://support.apple.com/en-us/HT212842 6. M1に慣れてしまった 7. MacBook Pro M1 Pro 32GBなら，LLVMビルドも360秒！ 8. Xcode Cloud 9. 使える人が増えたみたい 10. 他のCIでビルドして，Xcode Cloudで署名がよい・・・というバッドノウハウ 11. Xcode Cloudへの過大な期待は禁物 12. LLVM Buildの話 13. Safariの検索やっぱバグってる・・・全員で発現・・・タブをたくさん開いたときに，右側のタブでなりやすい． 14. MontereyのCoreBluetoothのバグ 15. iTerm2のクラック怖いんですけど 16. セキュリティの勉強 17. 図解即戦力 暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書 https://www.amazon.jp/dp/429712307X 18. iOSの脆弱性 19. URLスキーマの踏み台 20. WebViewの扱い 21. セキュリティ https://github.com/coky-t/owasp-mstg-ja 22. 技術アップロードサイトのあるべき姿とは・・ 23. StackOverflowのアメリカ版は機能している 24. up vote 25. down vote 26. down voteには，reputationが必要 27. reviewは大変よ 28. セキュリティの技術の話・・・・数学の話，運用の話

Angular + Ionic = ❤️In this episode of the Angular Show, we had the opportunity to sit down and chat with Max Lynch, the co-founder of Ionic. If you haven't heard of Ionic, it's a set of components for rendering native controls on iOS and Android that enables web developers to build apps that are executed on phones and tablets that include core native device functionality. As web developers we are really good at creating applications that use a template (HTML) that is styled (CSS) and is dynamic and interactive (JS). If you think about it, that sounds like a lot of the apps that are available in Google Play and the App Store. Further, as Max points out, it's really about using the GPU to render bitmaps to the screen, which a webview is more than capable of doing. So, why not create the apps of today and the future using a stack like Angular and Ionic? In this episode, Max shares the history of how they got started with Ionic, from rebuilding Cordova and PhoneGap, to solving the developer experience using new tooling, building the component view library, and Capacitor, an open-source cross-platform native bridge built and supported by the Ionic team.

We talk with Dominic Letz about running Elixir on an Android phone installed in an APK which hosts a LiveView application accessed through a WebView! All while also pursuing a Web 3.0 architecture of being decentralized! Wow! There's a lot going on here! Oh, and the tech is OpenSource! Elixir Community News - https://github.com/phoenixframework/phoenix/blob/master/CHANGELOG.md#162-2021-10-08 (https://github.com/phoenixframework/phoenix/blob/master/CHANGELOG.md#162-2021-10-08) – Phoenix 1.6.1 and 1.6.2 were released. - https://twitter.com/mcrumm/status/1446594887034408960 (https://twitter.com/mcrumm/status/1446594887034408960) – Michael Crumm explains 1.6.2. It's cool! We all make mistakes! - https://www.cnbc.com/2021/10/05/facebook-says-sorry-for-mass-outage-and-reveals-why-it-happened.html (https://www.cnbc.com/2021/10/05/facebook-says-sorry-for-mass-outage-and-reveals-why-it-happened.html) – Facebook major outage. Cause? Bad BGP (Border Gateway Protocol) config, bugs in the "don't let that happen" checks, and being physically locked out of their offices because they couldn't be authenticated. - https://dev.to/oliverandrich/adding-bootstrap-to-a-phoenix-1-6-project-hfe (https://dev.to/oliverandrich/adding-bootstrap-to-a-phoenix-1-6-project-hfe) – How to setup Bootstrap with esbuild - https://twitter.com/elixirmembrane/status/1445768307643088897 (https://twitter.com/elixirmembrane/status/1445768307643088897) – Membrane Framework getting a big update. Ability to record WebRTC sessions to MP4 and WebM. - https://thinkingelixir.com/podcast-episodes/043-membrane-with-marcin-lewandowski/ (https://thinkingelixir.com/podcast-episodes/043-membrane-with-marcin-lewandowski/) – Previous discussion about Membrane - https://twitter.com/josevalim/status/1446443166048129028 (https://twitter.com/josevalim/status/1446443166048129028) – MSSQL / TDS Database driver for Elixir looking for new maintainer - https://github.com/elixir-ecto/tds/issues/128 (https://github.com/elixir-ecto/tds/issues/128) – TDS project issue with discussion - https://nts.strzibny.name/12factor-elixir-phoenix-releases/ (https://nts.strzibny.name/12factor-elixir-phoenix-releases/) – 12-Factor app guide by Josef Strzibny updated for Phoenix 1.6 and esbuild - https://12factor.net/ (https://12factor.net/) – 12-Factor is about "how to design your applications" - https://hexdocs.pm/phoenix_bakery/PhoenixBakery.html (https://hexdocs.pm/phoenix_bakery/PhoenixBakery.html) – New library for Phoenix, about better compression for Phoenix assets - https://twitter.com/fhunleth/status/1446448994310369281 (https://twitter.com/fhunleth/status/1446448994310369281) – Nerves get's bluetooth support enabled on hardware like the RPi3 while working in Nerves Livebook v0.2.25 - https://www.elixirconf.com/ (https://www.elixirconf.com/) – ElixirConf 2021 Do you have some Elixir news to share? Tell us at @ThinkingElixir (https://twitter.com/ThinkingElixir) or email at show@thinkingelixir.com (mailto:show@thinkingelixir.com) Discussion Resources - https://github.com/elixir-desktop/android-example-app/ (https://github.com/elixir-desktop/android-example-app/) - https://github.com/elixir-desktop/desktop-example-app (https://github.com/elixir-desktop/desktop-example-app) - https://github.com/elixir-desktop (https://github.com/elixir-desktop) - https://diode.io/ (https://diode.io/) - https://github.com/erlang/otp/blob/master/HOWTO/INSTALL-ANDROID.md (https://github.com/erlang/otp/blob/master/HOWTO/INSTALL-ANDROID.md) - https://github.com/elixir-sqlite/exqlite (https://github.com/elixir-sqlite/exqlite) - http://www.wings3d.com/ (http://www.wings3d.com/) - https://diode.io/resources/download/#diode-drive-download (https://diode.io/resources/download/#diode-drive-download) - https://github.com/boydm/scenic (https://github.com/boydm/scenic) - https://www.forbes.com/sites/forbestechcouncil/2020/01/06/what-is-web-3-0/?sh=6f627da58dfb (https://www.forbes.com/sites/forbestechcouncil/2020/01/06/what-is-web-3-0/?sh=6f627da58dfb) – Decentralized Web 3.0 approach - https://github.com/elixir-desktop (https://github.com/elixir-desktop) Guest Information - https://twitter.com/DominicLetz (https://twitter.com/DominicLetz) – on Twitter - https://github.com/dominicletz/ (https://github.com/dominicletz/) – on Github - https://elixirforum.com/u/dominicletz/summary (https://elixirforum.com/u/dominicletz/summary) – on Elixir Forum - https://diode.io/ (https://diode.io/) – Diode and blog Find us online - Message the show - @ThinkingElixir (https://twitter.com/ThinkingElixir) - Email the show - show@thinkingelixir.com (mailto:show@thinkingelixir.com) - Mark Ericksen - @brainlid (https://twitter.com/brainlid) - David Bernheisel - @bernheisel (https://twitter.com/bernheisel) - Cade Ward - @cadebward (https://twitter.com/cadebward)

We talk with Dominic Letz about running Elixir on an Android phone installed in an APK which hosts a LiveView application accessed through a WebView! All while also pursuing a Web 3.0 architecture of being decentralized! Wow! There's a lot going on here! Oh, and the tech is OpenSource! Show Notes online - https://thinkingelixir.com/podcast-episodes/069-elixir-on-mobile-with-dominic-letz The post #069 Elixir on Mobile with Dominic Letz appeared first on Thinking Elixir.

We talk with Elixir Core Team Member Aleksei Magusev about how he got involved in Elixir, what it's like being on the Core Team, some of his contributions, areas in Elixir that interest him, and his tips for learning a new programming language! He also shares some of his interests outside of computing. Meet Aleksei! Elixir Community News - https://github.com/phoenixframework/phoenixliveview/issues/1617 (https://github.com/phoenixframework/phoenix_live_view/issues/1617) – Initial proposal to bring slots to LiveView components. - https://twitter.com/elixirbookclub/status/1437034456037068804 (https://twitter.com/elixirbookclub/status/1437034456037068804) – Book Club started "Elixir in Action" - https://techcrunch.com/2021/09/09/supabase-raises-30m-for-its-open-source-insta-backend/ (https://techcrunch.com/2021/09/09/supabase-raises-30m-for-its-open-source-insta-backend/) – Supabase, which uses Elixir in their "realtime" project raised $30m - https://github.com/supabase/realtime (https://github.com/supabase/realtime) – Realtime project on github - https://twitter.com/BrooklinJMyers/status/1436744292391923714 (https://twitter.com/BrooklinJMyers/status/1436744292391923714) – New Podcast "Elixir Newbie" - https://twitter.com/josevalim/status/1436386868539662338 (https://twitter.com/josevalim/status/1436386868539662338) – Fly.io is now a sponsor of the Livebook project! - https://github.com/elixir-desktop/android-example-app/ (https://github.com/elixir-desktop/android-example-app/) – Android Application that embeds Elixir, uses a Webview to connect locally to the server, and renders using LiveView! - https://github.com/elixir-lang/elixir/pull/11246 (https://github.com/elixir-lang/elixir/pull/11246) – Mix Formatter Plugins PR - ElixirConf EU has happened! - https://github.com/elixir-lang/elixir/releases/tag/v1.12.3 (https://github.com/elixir-lang/elixir/releases/tag/v1.12.3) – Elixir 1.12.3 released Do you have some Elixir news to share? Tell us at @ThinkingElixir (https://twitter.com/ThinkingElixir) or email at show@thinkingelixir.com (mailto:show@thinkingelixir.com) Discussion Resources - https://forzafootball.com/ (https://forzafootball.com/) - https://tech.forzafootball.com/blog/binary-parsing-optimizations-in-elixir (https://tech.forzafootball.com/blog/binary-parsing-optimizations-in-elixir) – Blog post by Aleksei Magusev on the Forza Football site - https://github.com/celluloid/celluloid (https://github.com/celluloid/celluloid) - https://racket-lang.org/ (https://racket-lang.org/) - https://www.rubinius.com/about/ (https://www.rubinius.com/about/) - https://web.archive.org/web/20130422214345/http://www.matasano.com/articles/crypto-challenges/ (https://web.archive.org/web/20130422214345/http://www.matasano.com/articles/crypto-challenges/) – The Matasano Crypto Challenge isn't online anymore - this is from the Wayback Machine - https://hexdocs.pm/ex_unit/ExUnit.CaptureLog.html (https://hexdocs.pm/ex_unit/ExUnit.CaptureLog.html) - https://github.com/elixir-lang/elixir/pull/3390 (https://github.com/elixir-lang/elixir/pull/3390) – Early version of the capture_log work which was later simplified - https://github.com/kraftjectory/forgery (https://github.com/kraftjectory/forgery) - https://hex.pm/packages/forgery (https://hex.pm/packages/forgery) - https://hex.pm/packages/mint (https://hex.pm/packages/mint) - https://hex.pm/packages/finch (https://hex.pm/packages/finch) - https://en.wikipedia.org/wiki/Cache_stampede (https://en.wikipedia.org/wiki/Cache_stampede) - https://github.com/lexmag/cashmere (https://github.com/lexmag/cashmere) – Caching library Aleksei created and open sourced - https://cassandra.apache.org/_/index.html (https://cassandra.apache.org/_/index.html) - https://andrealeopardi.com/ (https://andrealeopardi.com/) - https://github.com/elixir-lang/elixir/pull/4430 (https://github.com/elixir-lang/elixir/pull/4430) – PR adding difference highlighting to ExUnit output - https://github.com/lexmag/elixir-style-guide (https://github.com/lexmag/elixir-style-guide) – He wrote the very early version of Elixir Style Guide Guest Information - https://twitter.com/lexmag (https://twitter.com/lexmag) – on Twitter - https://github.com/lexmag/ (https://github.com/lexmag/) – on Github Find us online - Message the show - @ThinkingElixir (https://twitter.com/ThinkingElixir) - Email the show - show@thinkingelixir.com (mailto:show@thinkingelixir.com) - Mark Ericksen - @brainlid (https://twitter.com/brainlid) - David Bernheisel - @bernheisel (https://twitter.com/bernheisel) - Cade Ward - @cadebward (https://twitter.com/cadebward)

静岡市の予約はなかなか進まないので、かかりつけ医院に電話したら、ありがたいことに予約できました。ただ、リスクもあるとは思うので、ちょい不安もありますけどね。まあそれでも打っておいた方が安心です。ちなみにインスタの「健康だよね」というアカウントで紹介されていた、ワクチンのリスクに関する動画はこちら。https://smart.discussvision.net/smart/tenant/takarazuka/WebView/rd/speech.html?council_id=36&schedule_id=10&playlist_id=6&speaker_id=28&target_year=2021&fbclid=IwAR3I1Mttgm172AQ9f6hftZ-qz3sNmbKLLaHoRNmcJa2Rde-Kfr_oF7bPh8Q　【今日も家族でボードゲーム！】 Himalayaで聴く→https://bit.ly/3fLPavS stand fmで聴く→https://bit.ly/2RgY2QB Radiotalkで聴く→https://bit.ly/3x61g8X Podcastで聴く→https://www.podpage.com/kazobodo/ 【ゆるたび日本平（2021年日本平動画コンテスト審査員賞受賞作品 ）】 https://youtu.be/VyyexzAD6x8 【あわせて聴きたい】ながらcast186 【小さな店のIT奮戦記】新方式のウェビナーなんとか成功？！　https://anchor.fm/nagaracast/episodes/cast186-IT-eu65p9　【「ながらcast」とは】 静岡市に住む50代後半のササユキが、通勤足りずに詰んでいる現状をなんとかしようと、定年後の収入源を模索する日々を中心に、この春、留年して内定取消になった息子の就活、仕事である小さな個店のドタバタＩＴ奮戦記、個人的なデジタル生活へのチャレンジ、夫婦の「ゆる旅しずおか」、オヤジのファッション、映像クリエイターへのチャレンジなどについて、お話します。 ご意見・ご感想は、#ながらcast のハッシュタグをつけて Twitter で呟いてください。【YouTubeチャンネル sasaTube】https://youtube.com/channel/UCFyi3x8zvUsXLdc0B3C6uVw 【おたよりはこちらでも】 https://forms.gle/pHX67DKKGUZTcgid7

On the show this week, Justin Morris (who you might remember from The UC Architects Podcast) - former MVP and now Microsoft Teams Meeting Rooms specialist joins us to share what he's seeing with customers today as they adopt Hybrid working. We've heard the theory - what are the execs asking for as they begin to use board rooms again? And Paul and I deep-dive into Teams V2.0 - Angular vs React, what is Webview 2.0 - we go deep - you'll find out a lot of useful information on what's under the hood here.Plus of course Exchange Updates, news on Windows 11 since the last show, and new Microsoft 365 features dropping into your tenant soon that you'll need to know about..

Qué cambia en Windows 11, cómo conseguirlo y preparar tu ordenador / Instagram permite publicar desde web / WhatsApp entorpece los audios / Nvidia Canva nativo / Metano filtrado en toda Europa Patrocinador: La sostenibilidad tan importante como la seguridad, y ¿quién mejor que Volvo para ir hacia el futuro? En 2025 la mitad de los coches que venda serán eléctricos, y en 2030 todos lo serán. El nuevo Volvo XC40 Recharge https://www.volvocars.com/es/ es el primer vehículo 100% eléctrico de la compañía. — Descubre todo sobre los coches eléctricos de Volvo en volvocars.es https://www.volvocars.com/es/. Qué cambia en Windows 11, cómo conseguirlo y preparar tu ordenador / Instagram permite publicar desde web / WhatsApp entorpece los audios / Nvidia Canva nativo / Metano filtrado en toda Europa  Microsoft anunció Windows 11, su nuevo sistema operativo que llegará en 2022. Una serie de cambios estéticos y de fondo técnico https://www.geeknetic.es/Noticia/22319/Llega-Windows-11-centrado-en-el-Diseno-de-la-Interfaz-y-Optimizacion-de-Tareas.html que de momento no lo separarán mucho de la situación actual con Windows 10. — Lo más interesante:  Podrás instalar aplicaciones de Android https://es.gizmodo.com/windows-11-podra-instalar-aplicaciones-de-android-1847165801 desde la tienda de Microsoft, que en realidad beberá de la tienda de Amazon. — Estarán pre-optimizadas para x86 usando tecnología de Intel https://www.engadget.com/intel-bridge-windows-11-android-apps-181527847.html, que también funcionará en equipos AMD https://pocketnow.com/android-apps-on-windows-11-will-run-on-amd-powered-machines, claro.  La lista de CPUs soportadas es bastante corta https://docs.microsoft.com/en-us/windows-hardware/design/minimum/supported/windows-11-supported-intel-processors. Solo Intel de 8ª generación y en adelante, Ryzen 2000 y en adelante. Un golpe duro para millones de consumidores que se quedarán en Windows 10.  Se necesita TPM 2.0 https://microsofters.com/178589/como-habilitar-tpm-2-0-y-arranque-seguro-para-actualizar-a-windows-11/ y aunque muchos ordenadores nuevos lo tienen, está desactivado. Aquí una sencilla guía para tenerlo listo.  Estará disponible desde la semana que viene en beta https://blogs.windows.com/windows-insider/2021/06/24/preparing-for-insider-preview-builds-of-windows-11/ para todos aquellos que estén apuntados al programa Insider, como las versiones rápidas de Windows 10.  Microsoft Teams será WebView 2 https://microsofters.com/178647/microsoft-teams-se-pasa-a-webview2-para-ser-mas-rapida/ en vez de Electron, y en Windows 11 está integrado https://es.digitaltrends.com/computadoras/microsoft-teams-windows-11/ ahora a nivel del sistema operativo.  Software que dice adiós y no se instalarán o mostrarán por defecto https://es.gizmodo.com/todo-lo-que-microsoft-ha-eliminado-de-windows-11-1847169345: Skype, Internet Explorer, Cortana, modo tableta, Wallet, OneNote, y alguna más. Disculpad el retraso de esta edición, y que esté absorbida casi por completo por Windows 11. Os enviaré otra con más enlaces tecnológicos interesantes.  Instagram permite publicar desde la web. Un cambio histórico que de momento ya está disponible para algunos usuarios https://eloutput.com/noticias/redes-sociales/instagram-publicar-navegador-web/. Simplemente aparecerá un botoncito de añadir en el menú superior derecho. La empresa no ha publicado cuando estará disponible para todos. — A mí de momento no me sale.  Otro cambio: nos mostrarán mucho más contenido de cuentas que no seguimos https://www.elespanol.com/omicrono/software/20210624/instagram-mostrara-cuentas-no-sigues-fotos-amigos/591441483_0.html.  Ahora se puede compartir un tweet en las historias de Instagram de forma nativa https://eloutput.com/redes-sociales/twitter/publicar-tweets-instagram-stories/, sin necesidad de hacer pantallazos.  WhatsApp elimina la barra de progreso de audios en la beta. No sabemos si es una prueba cambiando interfaces o quedará como un ajuste, pero podría ser un cambio drástico https://www.proandroid.com/whatsapp-acaba-de-eliminar-una-funcion-esencial-para-todos-los-usuarios/ con el uso tradicional de las notas de voz. — Si se implementa... ¿quizá podría ayudar a acortarlas?  El mayor fabricante de ordenadores especializados para cripto pausa su venta. Los cambios legales en China están haciendo a muchos mineros vender su equipamiento, lo que ha tirado por los suelos los precios de reventa. Ahora Bitmain también pausará sus ventas https://es.cointelegraph.com/news/bitmain-reportedly-suspends-bitcoin-miner-orders-amid-booming-secondhand-supply mientras espera que vuelvan las vacas gordas y no competir con un mercado saturado.  Cientos de estaciones y fábricas en toda Europa filtran metano a la atmósfera. Las emisiones de este preciado (y muy contaminante) gas no están reguladas en el sector energético, así que la industria europea en general no está vigilando si se escapa de sus contenedores o toberas de gas natural y otros, como se ha demostrado con una cámara especial https://www.reuters.com/business/environment/exclusive-gas-infrastructure-across-europe-leaking-planet-warming-methane-video-2021-06-24/. Preocupante.  Nvidia publica la beta de Canvas, su herramienta de ilustración con IA. Demostrado hace tiempo y disponible ahora para Windows, con solo unos simples trazos de elementos https://www.youtube.com/watch?v=9u_08---oEw como montañas, hierba, arena, cielo, etc. y crear imágenes foto-realistas. Ocupa más de 1 GB https://www.nvidia.com/en-gb/studio/canvas/, y voy a tirarme todo el finde usándola.  Podéis usar la versión web http://nvidia-research-mingyuliu.com/gaugan/ disponible hace un tiempo, que entiendo que utiliza el mismo software pero ejecutado en remoto.

Wir haben ein Update für euch zum Android WebView Problem, das im März viele Android-Apps zum Absturz gebracht hat. Ein Safe Mode soll laut Google zukünftig solche Probleme verhindern können.Docker Desktop unterstützt jetzt Apple Silicon, was Fabi zu verstehen geholfen hat, wie Docker überhaupt das Erstellen für verschiedene Plattformen umgesetzt hat.Für uns sind außerdem die Änderungen in Flutter super spannend: Eines der größten bestehenden Probleme von Flutter, das starke Ruckeln von Animation nach Appstart, ist nun behoben worden und wird bald den Weg in den offiziellen Master Branch finden.Auch wenn Sebi letzte Woche noch ganz aufgeregt war, dass Node.js 16 rausgekommen ist, halten sich die Neuerungen in Grenzen. Was schön ist: Die Promise API für Timer ist jetzt stable.Pick of the Day von unserem Hörer Christian: Bracket Pair Colorizer 2Schreibt uns!Schickt uns eure Themenwünsche und euer Feedback.podcast@programmier.barFolgt uns!Bleibt auf dem Laufenden über zukünftige Folgen und beteiligt euch an Community-Diskussionen.TwitterInstagramFacebookMeetup 

Neste episódio tivemos notícias sobre Google está sozinho com o FLoC, APIs do Node 16 ganha suporte ao Apple Silicon, WordPress ganha super plugin, GitHub Actions no CLI, Linux bloqueia contribuições de universidade, Google corrige WebView do Android e mais. Confira o Compilado #005, com as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 17/04 a 23/04! Além de trazer e comentar as notícias, abrimos espaço no Compilado para os comentários dos nossos seguidores, aproveitamos para explicar sobre os vídeos que publicamos na semana no YouTube e também fazemos menções honrosas aos membros do Clube dos CDFs, nosso membros no YouTube. Hosts: Somos Gabriel Fróes e Vanessa Weber, um casal de programadores que dá as caras desde 2016 no canal Código Fonte TV no YouTube. Links:

Neste episódio tivemos notícias sobre Google está sozinho com o FLoC, APIs do Node 16 ganha suporte ao Apple Silicon, WordPress ganha super plugin, GitHub Actions no CLI, Linux bloqueia contribuições de universidade, Google corrige WebView do Android e mais. Confira o Compilado #005, com as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 17/04 a 23/04! Além de trazer e comentar as notícias, abrimos espaço no Compilado para os comentários dos nossos seguidores, aproveitamos para explicar sobre os vídeos que publicamos na semana no YouTube e também fazemos menções honrosas aos membros do Clube dos CDFs, nosso membros no YouTube. Hosts: Somos Gabriel Fróes e Vanessa Weber, um casal de programadores que dá as caras desde 2016 no canal Código Fonte TV no YouTube. Links:

Los temas del día: Reddit y su versión de Clubhouse https://infosertec.com.ar/2021/04/21/reddit-y-su-version-de-clubhouse/ Google Pixel 5a 5G tendrá un Snapdragon 765G https://infosertec.com.ar/2021/04/21/google-pixel-5a-5g-tendra-un-snapdragon-765g/ Es oficial que Samsung Galaxy S20 FE 4G tendrá chipset Snapdragon 865 https://infosertec.com.ar/2021/04/21/es-oficial-que-samsung-galaxy-s20-fe-4g-tendra-chipset-snapdragon-865/ Un vistazo a los próximos Samsung Galaxy Book que se lanzaran el 28 de abril https://infosertec.com.ar/2021/04/21/un-vistazo-a-los-proximos-samsung-galaxy-book-que-se-lanzaran-el-28-de-abril/ Instagram finalmente nos ayudará a esquivar los DM abusivos escondiéndolos en una carpeta oculta https://www.genbeta.com/redes-sociales-y-comunidades/instagram-finalmente-nos-ayudara-a-esquivar-dm-abusivos-escondiendolos-carpeta-oculta? Motorola Moto G20 Google soluciono el problema de WebView de Android https://androidcommunity.com/webview-safe-mode-to-prevent-android-apps-from-crashing-20210420/ MediaTek sera el primero en lanzar un chipset de 4 nm http://mobile.yesky.com/328/725707328.shtml Microsoft está trabajando en una nueva tienda para Windows 10 https://www.windowscentral.com/windows-10-big-changes-coming-app-store? APOYANOS DESDE PAYPAL https://www.paypal.me/arielmcorg APOYANOS DESDE PATREON https://www.patreon.com/radiogeek Podes seguirme desde Twitter @arielmcorg (www.twitter.com/arielmcorg) También desde Instagram @arielmcorg (www.instagram.com/arielmcorg) Sumate al canal de Telegram #Radiogeekpodcast (http://telegram.me/Radiogeekpodcast)

Listen to a short-form recap or roundup of all the top 9to5Google stories of the previous 24 hours. 9to5Google Daily is available on Spotify,Google Podcasts, Amazon, iTunes and Apple’s Podcasts app, Stitcher, or through our dedicated RSS feed for Pocket Casts and other podcast players. New episodes of 9to5Google Daily are recorded every weekday. Subscribe to our podcast in Google Podcasts or your favorite podcast player to guarantee new episodes are delivered as soon as they’re available. Why not add the 9to5Google Daily to your Google Assistant Routine for a quick morning update? Learn how to add us directly to your Assistant Routines right here. Follow Damien: Damien Wilde Stories discussed in this episode: Google explains why WebView crashed Android apps last month and upcoming mitigations You can now subscribe to Ubisoft+ from within the Stadia app Fitbit expands Stress Score tool to more fitness trackers, smartwatches including Versa 3 Wear OS H-MR2 update rolling out to TicWatch Pro 3 w/ Snapdragon Wear 4100 improvements Drop us a line at gtips@9to5g.com. You can also rate us in Google Podcasts, Spotify, Apple Podcasts or recommend us in Pocket Casts to help more people discover the show!

Tech News and Commentary Dave and the team discuss Google pushing a broken WebView update, Intel’s new patent fine, and more. Steve in Lake Villa, Illinois listens to the podcasts and is calling via the AskDave button on the IT site and asked: “I kind of invested in Google smart speakers. My wife bought me […]

Muchos usuarios de Android están experimentando problemas con sus dispositivos, principalmente porque las aplicaciones aplicaciones se cierran solas, y aunque parece que es de manera aleatoria, sucede con muchas, desde las más sencillas hasta las más famosas. Gmail, Twitter, PayPal, Outlook entre otras son las víctimas. Qué está pasando y como se soluciona, aquí te lo contaré.

S2 EP1.本次節目的涵蓋日期是3月9號到3月23號，科技部分：Android System Webview大災情、Intel第11代處理器3月30號解禁、看得到買不到的空氣顯卡、Intel重返遊戲顯卡市場、三星Note系列今年無新機、三星中階新機三胞胎；遊戲部分：GTA Online讀取緩慢問題被民間高手修正、赤燭遊戲自家網路商店上線與新作開發情報、微軟預計在Win10上導入自動HDR功能、尼爾上架微軟商店引爆Steam平台大量負評 節目簡介：每週五播出的科技週報，將由主持人「柚」彙整前一週的科技與遊戲大小事，帶給你最新、最快、最好吸收的情報資訊，讓你隨時隨地跟上潮流！ *節目中若有任何錯誤之處，還請聽眾不吝賜教 *本集使用音樂：Jason Mraz + Colbie Caillat - Lucky高橋洋子 - 残酷な天使のテーゼ杜美心（劉芷融） - 碼頭姑娘河野万里奈 - 壊レタ世界ノ歌 Powered by Firstory Hosting

En este capítulo tratamos el tema del fallo de la actualización del servicio Android service webview que ha hecho que miles de teléfonos tengan cierres de aplicaciones, lo que nos ha llevado a tener una riada de gente acudiendo a los servicios técnicos para solucionar el problema.Damos también una pincelada a la presentación de los nuevos One Plus 9 y 9 pro.Canal de Twitch: https://www.twitch.tv/geekpollasTwitter y Telegram: @geekpollas @geekpakoGrupo de Telegram: https://t.me/joinchat/RTsWMKAM0gjrKrxdCorreo y Paypal: geekpollas@gmail.comAfiliado Amazon: https://amzn.to/2Ax2eTSAfiliado Lowi: http://aklam.io/dJ6SBj

Hoje vamos falar sobre a baboseira do WhatsApp 2 que tomou as redes sociais, o bug do Android que tá travando um monte de aplicativo e um site que vai pagar 13 mil reais para quem ficar 24 horas sem qualquer tipo de tecnologia. Confira! CRÉDITOS Narração: Felipe Payão Captação: Felipe Payão Roteiro: Felipe Payão Edição: Rafael Nogoceke O Hoje no TecMundo traz as notícias de destaque no mundo da tecnologia, de segunda a sexta (exceto feriados), no fim da tarde. Confira as notícias completas de hoje no site: 1) Google atualiza Chrome e WebView para corrigir falhas no Android 2) Microsoft negocia compra do Discord por US$ 10 bilhões 3) OnePlus lança série OnePlus 9, com supercâmera e 5G 4) Site vai pagar US$ 2,4 mil para quem ficar 24 horas sem tecnologia 5) WhatsApp 2? Brincadeira com app vira trending topic no Brasil

On All About Android, Jason Howell, Ron Richards, and Florence Ion discuss how many Android devices have experienced debilitating app crashes related to Android's WebView system and Google's fix. For the full episode, visit twit.tv/aaa/517 Hosts: Jason Howell, Florence Ion, and Ron Richards You can find more about TWiT and subscribe to our podcasts at https://podcasts.twit.tv/

Android 12 Developer Preview 2 is here with better notification security and picture-in-picture enhancements Here's everything new in Android 12 Developer Preview 2 Android 12 DP2 Hidden Features Changelog: New Search widget, Taskbar, and more! Android 12 DP2 hints at a future Pixel device with an under-display fingerprint scanner PSA: If your Android apps keep crashing, uninstall 'WebView' Samsung bets big on foldable smartphones amid chip crunch Samsung Warns of Severe Chip Crunch While Delaying Key Phone OP 9 hands-on and OP 9 Pro Review OnePlus snubs Google's Wear OS, announces a $159 smartwatch Google readying crowdsourced 'App install optimization' in the Play Store Here's a sneak peek at Aurora Store v4, a big update to the open-source Play Store client Read our show notes here: https://bit.ly/39bTy3n Hosts: Jason Howell, Florence Ion, and Ron Richards Subscribe to All About Android at https://twit.tv/shows/all-about-android. Sponsors: hover.com/twit sandisk.com/aaa

Android 12 Developer Preview 2 is here with better notification security and picture-in-picture enhancements Here's everything new in Android 12 Developer Preview 2 Android 12 DP2 Hidden Features Changelog: New Search widget, Taskbar, and more! Android 12 DP2 hints at a future Pixel device with an under-display fingerprint scanner PSA: If your Android apps keep crashing, uninstall 'WebView' Samsung bets big on foldable smartphones amid chip crunch Samsung Warns of Severe Chip Crunch While Delaying Key Phone OP 9 hands-on and OP 9 Pro Review OnePlus snubs Google's Wear OS, announces a $159 smartwatch Google readying crowdsourced 'App install optimization' in the Play Store Here's a sneak peek at Aurora Store v4, a big update to the open-source Play Store client Read our show notes here: https://bit.ly/39bTy3n Hosts: Jason Howell, Florence Ion, and Ron Richards Subscribe to All About Android at https://twit.tv/shows/all-about-android. Sponsors: hover.com/twit sandisk.com/aaa

Comentamos el error que se detectó ayer en Android, y porque fallaban diferentes aplicacion; y si aun persiste el error como arreglarlo.

On All About Android, Jason Howell, Ron Richards, and Florence Ion discuss how many Android devices have experienced debilitating app crashes related to Android's WebView system and Google's fix. For the full episode, visit twit.tv/aaa/517 Hosts: Jason Howell, Florence Ion, and Ron Richards You can find more about TWiT and subscribe to our podcasts at https://podcasts.twit.tv/

On All About Android, Jason Howell, Ron Richards, and Florence Ion discuss how many Android devices have experienced debilitating app crashes related to Android's WebView system and Google's fix. For the full episode, visit twit.tv/aaa/517 Hosts: Jason Howell, Florence Ion, and Ron Richards You can find more about TWiT and subscribe to our podcasts at https://podcasts.twit.tv/

Android 12 Developer Preview 2 is here with better notification security and picture-in-picture enhancements Here's everything new in Android 12 Developer Preview 2 Android 12 DP2 Hidden Features Changelog: New Search widget, Taskbar, and more! Android 12 DP2 hints at a future Pixel device with an under-display fingerprint scanner PSA: If your Android apps keep crashing, uninstall 'WebView' Samsung bets big on foldable smartphones amid chip crunch Samsung Warns of Severe Chip Crunch While Delaying Key Phone OP 9 hands-on and OP 9 Pro Review OnePlus snubs Google's Wear OS, announces a $159 smartwatch Google readying crowdsourced 'App install optimization' in the Play Store Here's a sneak peek at Aurora Store v4, a big update to the open-source Play Store client Read our show notes here: https://bit.ly/39bTy3n Hosts: Jason Howell, Florence Ion, and Ron Richards Subscribe to All About Android at https://twit.tv/shows/all-about-android. Sponsors: hover.com/twit sandisk.com/aaa

Android 12 Developer Preview 2 is here with better notification security and picture-in-picture enhancements Here's everything new in Android 12 Developer Preview 2 Android 12 DP2 Hidden Features Changelog: New Search widget, Taskbar, and more! Android 12 DP2 hints at a future Pixel device with an under-display fingerprint scanner PSA: If your Android apps keep crashing, uninstall 'WebView' Samsung bets big on foldable smartphones amid chip crunch Samsung Warns of Severe Chip Crunch While Delaying Key Phone OP 9 hands-on and OP 9 Pro Review OnePlus snubs Google's Wear OS, announces a $159 smartwatch Google readying crowdsourced 'App install optimization' in the Play Store Here's a sneak peek at Aurora Store v4, a big update to the open-source Play Store client Read our show notes here: https://bit.ly/39bTy3n Hosts: Jason Howell, Florence Ion, and Ron Richards Subscribe to All About Android at https://twit.tv/shows/all-about-android. Sponsors: hover.com/twit sandisk.com/aaa

On All About Android, Jason Howell, Ron Richards, and Florence Ion discuss how many Android devices have experienced debilitating app crashes related to Android's WebView system and Google's fix. For the full episode, visit twit.tv/aaa/517 Hosts: Jason Howell, Florence Ion, and Ron Richards You can find more about TWiT and subscribe to our podcasts at https://podcasts.twit.tv/

Hablo de un problema de última hora que afecta a varios usuarios de Android

An airhacks.fm conversation with Johan Vos (@johanvos) about: Gluon Mobile, JavaFX was supposed to replace Swing, Swing and AWS were created in a hurry, JavaFX is a significant improvement, Java started on Star7, JavaFX ran on an iPad during JavaOne, the source of JavaFX was already in a good shape, creating native apps with GraalVM and JavaFX, JavaFX does not require to install Java on mobile device, SubstrateVM helps with cross-compiling Java to native code, Apache Cordova, shipping JavaFX applications to AppStores, SpaceFX, JavaFX on RaspberryPI, JavaFX on an iPhone emulator, JavaFX provides similar experience to flutter, the TooManyLanguagesExceptions, the Google Cemetery, Gluon Attach framework helps with sensor integration, JavaFX's WebView uses WebKit on iOS, building a hybrid app with WebComponents and JavaFX, using CustomEvents to communication between Web Components and JavaFX, on desktop JavaFX uses recent WebKit builds, native vs. cross platform look and feel, JavaFX ships with material design based look and feel, JavaFX is GPU accelerated on mobile, JavaFX uses OpenGL, EGL, JEP 382: New macOS Rendering Pipeline, Apple's M1 Chip simplifies JavaFX development, JavaFX can run as Java application, or as native executable, JavaFX transpiles with GraalVM to native application, JavaFX transpiles to native C iOS code, the microprofile.training covering a blog engine, Gluon provides commercial support and roadmap priority shifting, openJFX vs. JavaFX is like openJDK vs Java, Gluon Mobile is a commercial product, Gluon CloudLink integrates with serverless runtimes, fnproject is used as serverless platform, Gluon Cloudlink could use MicroProfile GraphQL as backend, ODATA is useful to integrate frontend with data-rich backends, Apache Olingo, Oracle is a great steward of Java, Johan Vos on twitter: @johanvos, Johan's company: Gluon

An airhacks.fm conversation with Johan Vos (@johanvos) about: Java FX, CodeONE and JavaONE or conferences as trainings camp, Java FX is more applicable now to mobile devices, Java FX and GraalVM teams are working together to improve performance, openjfx.io the new home of JavaFX, Java is a perfect technology for client development, using Java on the client and on the server greatly increases productivity, the beginnings of JavaFX, JavaFX on an iPad, RoboVM the Java to native compiler, RoboVM was used to deploy JavaFX to iOS, JavaFX has the same codebase on mobile and on desktop, Johan Vos is co-lead of openjfx, Oracle is open for community contributions to JavaFX, Oracle provides support for Java 8, what also includes JavaFX 8, JavaFX frontend also makes a Java backend more appealing, openJFX github mirror, openJDK project skara, gluon JavaFX releases, Neil Young on JavaONE, RoboVM was aqcuired by xamarin then Xamarin was acquired by microsoft, RoboVM is still opensource, openJDK mobile project, Android is more problematic than iOS, to run Java 11, Zero: interpreter only openJDK, GraalVM supports LLVM and so iOS and Android platforms, SubstrateVM is like tree shaking for Java, JavaFX UI controls, openJFX controls, main goal of openJFX is long term maintainability, TilesFX JavaFX library for Dashboards, TornadoFX JavaFX for Kotlin, JavaFX charts by DLSC, JFX Days Zurich, JavaFX 3D Visualization and Component Library FXyz3D, SceneBuilder downloads are increasing, JavaFX is comparable to ionic, flutter and Reactive Native, the future of JavaFX is stable, migration from JavaFX 8 to JavaFX 9 had breaking changes caused by the introduction of Java 9 modules, Java's total costs of ownership are low, Gluon Attach allows integration of native device's sensors, JavaFX comes with a WebView which can be used as a bridge, JavaFX WebView is based on recent WebKit, GluonMaps, Gluon CloudLink, Gluon provides LTS support for JavaFX, Gluon Mobile Johan Vos on twitter: @johanvos, Johan's company: Gluon

Webview, PWA mają zalety. Nie każda aplikacja musi być hybrydowa. Natywne aplikacje nie są jedynym rozwiązaniem. Co robić, gdy mamy ograniczony budżet, a klient naciska na konkretny rodzaj aplikacji? Jaki jest wspólny mianownik dla wszystkich aplikacji? W tym podkaście przejdziemy przez możliwe podejścia w wytwarzaniu aplikacji mobilnych i opowiemy jak dobierać rozwiązanie w zależności od wymagań projektu. Chcemy Was uspokoić. Aplikacja może być tania i dobra jednocześnie. Kluczem są potrzeby Klienta. Artykuł: http://bit.ly/pwaNativeHybridPrezentacja na YT: http://bit.ly/nativePWA Kontakt: Krzysztof: https://www.linkedin.com/in/krzysztofwojewodzic/ Mail: krzysztof.wojewodzic@escola.pl Jędrzej: https://www.linkedin.com/in/jedrzejpaulus/ Mail: jedrzej.paulus@gmail.com   Muzyka: Kevin MacLeod Werq Kevin MacLeod (incompetech.com)Licensed under Creative Commons: By Attribution 4.0 License/mix by Jedrzej Paulushttps://creativecommons.org/licenses/by/4.0/

Episode kali ini Gilang Ramadhan akan membahas soal WebView di Android. Versi video dapat diakses di sini. Kelas Menjadi Android Developer Expert di Dicoding #android #podcast #belajarandroid #menjadiexpert #developer #made

Всем привет! У нас новый подкаст, в нем мы поговорили с Русланом — руководителем медиабаинг агентства Adsleader. Вместе с Русланом мы разобрались в том, что такое WebView приложения и как с ними работать. Узнали о том, как лить на гемблинг с Facebook с их помощью. Руслан рассказал нам о том, как Adsleader создает и запускает кампании с помощью этих приложений, и с какими проблемами они сталкиваются. В конце бонус — Руслан готов поделиться своим опытом и дать несколько советов тому, кто хочет начать работать с WebView приложениями. Для участия в конкурсе нужно сделать репост этой записи. А 20-ого мая мы случайным образом выберем победителя! Если по тем или иным причинам Вам неудобно слушать подкаст, мы сделали для Вас краткую текстовую выжимку из него. Прочесть ее можно по ссылке: https://zorbasmedia.ru/zorbasmedia-podcast-epizod-9/ ⚡️ Спонсор нашего подкаста: Партнерская сеть olimob.com. Если вы хотите работать с gambling и betting офферами, пишите в Skype: live:OliMob

Всем привет!У нас новый подкаст, в нем мы поговорили с Русланом — руководителем медиабаинг агентства Adsleader.Вместе с Русланом мы разобрались в том, что такое WebView приложения и как с ними работать. Узнали о том, как лить на гемблинг с Facebook с их помощью.Руслан рассказал нам о том, как Adsleader создает и запускает кампании с помощью этих приложений, и с какими проблемами они сталкиваются.В конце бонус — Руслан готов поделиться своим опытом и дать несколько советов тому, кто хочет начать работать с WebView приложениями. Для участия в конкурсе нужно сделать репост этой записи. А 20-ого мая мы случайным образом выберем победителя!Если по тем или иным причинам Вам неудобно слушать подкаст, мы сделали для Вас краткую текстовую выжимку из него. Прочесть ее можно по ссылке: https://zorbasmedia.ru/zorbasmedia-podcast-epizod-9/⚡️ Спонсор нашего подкаста: Партнерская сеть olimob.com.Если вы хотите работать с gambling и betting офферами, пишите в Skype: live:OliMob

React Native vs Flutter vs WebView - Hybrid Mobile App Development)

In this episode Matt and Mike discuss when to start your business, a project, or whatever it is you're putting off. It's easy to get bogged down, luckily there are some tips and tricks to prevent it. Segment 1 - When to Start One of the things you’ll hear as an entrepreneur, and we’ve mentioned on the show several times is to “just start” This means that instead of being bogged down by “what ifs” that you should just jump in and get started on whatever it is you’re working on A prime example:  a would-be entrepreneur gets stuck reading into the basics of how to start a business, what pitfalls could happen, what issues may occur, etc. While it’s good to be prepared, you could read for years upon years and still have things to flip through. It’s generally better to understand the basics, do your best to cover all the bases that you need to and then just start - avoiding the paranoia of reading all the laws and issues that others have fallen into in the past. Definitely read and understand these things, but there is a point where you’ve read enough and it’s time to take action, there’s no way you can cover every base all the time or else you’ll never get started Keep in mind that being cautious isn’t a bad thing either, if you think you need to check a law or regulation out before doing something, then it’s best to check to ensure you’re operating legally. Just don’t get bogged down for years without acting, or your competition will fly by you. If you need to, get a lawyer to explain things to you in everyday terms so you can move forward with peace of mind Now that, that’s out of the way and you’re ready to get programming your new app, website, or whatever other program you’re working on, you’re bound to hit another wall - the learning curve Unless you’re experienced in everything your project needs, you’ll end up hitting a lot of walls, maybe you don’t even know where to start and this is another major point of contention that people get stuck in. Let’s say you want to make a PWA and you’re not experienced at all with service workers - a situation we recently found ourselves in - you could read example after example, look at tons of different solutions, try different plugins and even try different programming languages but at the end of the day you’re just reading up on what you want to be doing, you’re not doing what you want to be doing. Obviously guides, tutorials, and research do go a long way and are very valuable, but it’s easy to get stuck reading through the plethora of different ways that you can implement a solution for your given app and if it’s a passion project you want to make sure you’re using the best solution so you keep looking through different options and never actually start making that service worker (in our example) This is another major area where you need to “just start” The time differs from person to person, and from project to project, but at the end of the day you need/want to make that deliverable and we’re all human so it’s not going to be perfect (especially if you’re a beginner), so read up enough so you can navigate Google searches on that thing you’re working on and then just start making it If you end up pivoting a few times, who cares, as long as you keep moving towards the goal - you’ll end up learning way more working on the solution rather than just reading about it As a I said above the “just start” point is different for each person, and furthermore per project - in the next two segments we’ll be discussing our differing approaches to this problem Segment 2 - Matt’s Process When we first started our business, we had a hard time trying to figure out exactly what we needed to do We weren’t sure whether you needed a lawyer, or if you had to declare your business somewhere - there was nothing of the sort covered in our schooling other than the different types of businesses like partnerships, corporations, etc. We ended up calling a few places that didn’t get back to us, so we ended up having a meeting with a lawyer which gave us some information on opening, what at the time, was an IT business From that though, we decided that we wanted to go into web development due to an opportunity that popped up and from that pivot we ended up finding a business advisor that took us through the procedure, which ended up being very easy to get started We’ve mentioned this origin story in a past episode, but it’s an example of how we got bogged down in the beginning, but kept pushing through and then eventually just got started - later than we wanted - but we still finally got the job done In terms of a web development project, one of the more recent examples that we’ve mentioned on that show was learning about service workers, which resulted in getting bogged down in the research - my procedure for this was: Google “service workers” and read up on the very basics, learn how they work and how to implement them at a very high level so I know what tools I’ll need to have at my disposal Unfortunately, since service workers are complex and I was completely new to them, I had to read up on some related topics like promises and JS workers which gave me a bit of useful background information - and then I had to figure out how to get service workers to work with VueJS (this entire story is in this episode:) Dealing with advanced/complex topics are particularly easy to get bogged down in because there are a lot of variables that you, as a beginner, will not be aware of and will be tempted to read up on, leading to the loop of constant research In order to get out of the particular situation, I started narrowing the research from the initial very general searches, down to my particular situation of using service workers with vuejs That type of more specific research led me to a few examples that I was able to implement into my testing, which eventually led us to the solution that we’re working on now One of the telltale signs that I’ve read too much is that I have bookmarks/resources that have a lot of overlapping information. If I find myself bookmarking a variety of resources that essentially “read in circles” or are covering the exact same topics but in slightly different ways, I’ll generally stop researching and start implementing on the spot Segment 3 - Mike’s Process Feasibility assessment Can the chosen technology; plugin, library, framework, etc. Accomplish the set current and future goals of the application PWA example, simple buying app for a company that needs to work on all platforms Learning curve With my current knowledge, how long will it take me to Get started with this Accomplish my desired functionality Optimize for performance and extensibility PWA is standard html css js with a small jump in complexity in reference to service workers Get started Dive right into starting to use it, even if it’s just setting it up and running it’s most basic function I.e making a hello world application Create a PWA of the current products site More research Now that you have a basic understanding you can dive deeper into learning Watch videos, read tutorials, what ever learning style works for you Always do these with a goal, for instance trying to implement a feature on your roadmap, so that you are More motivated Not wasting any time Try to implement what you’re learning in parallel to learning about it In terms of PWA add offline functionality to app with service workers Web News - Apple Our main OS is Windows Had to buy a macbook to compile iOS apps using cordova and debug safari on an iPad Initially bought a 2011 13 inch macbook pro Did the job but was pretty slow even with a upgraded HDD to SSD Not enough screen real estate to use as a main machine if I’m traveling Also it does not officially support MacOS Mojave and the new xcode. Which means I wasn’t able to test my iOS apps on my updated iPad air 2 Bought a late 2013 15” macbook pro Retina which solved all those problems, but as I found out, Macbooks don’t have the greatest quality control and always have some weird issues Issue I had was a system process called kernel_task was taking up over 500% of the CPU processing threads and making my macbook pretty much unusable. This would usually happen when my Mac was at 100% battery and connected to power. A battery recalibration seemed to fix it but the Macbook still seems a little slow for it’s specs. Makes me think CPU is power throttling (def not temperature issues as they are fine) Had some moments where I didn’t know what to do, I don’t really want to buy a new Macbook having heard all it’s display and keyboard problems, especially considering it’s well over 3000 Canadian Really sucks when a manufacturer closes everything down and doesn’t give you any real options, not being able to do an iOS development on a windows or even linux machine locks me into only one option which hasn’t been a very good experience Considered building a hackintosh but again I need it to be potentially portable Wish I had the option of buying a windows laptop and running Macos on it, or being able to debug/compile in windows or even linux Don’t have any huge problems with MacOS as a whole, has its ups and downs like with any OS/ecosystem but the hardware has me really concerned Not being able to upgrade pretty much anything in the newer macbooks Having higher than industry standard failure rates on ‘premium’ priced machines Not having enough hardware options in the different models (especially at reasonable prices) Apple PWA and Webview support is also a disaster What should I do? Do you have hope for the future of Macbooks? You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub

Subodh, a software engineer leading the QUIC team in Menlo Park, joins us for episode 11 and talks with Mihaela and Pascal about Android networking. If you've never given much attention to the network protocols your app is using, listen to Subodh why you should give it a second though. You'll hear about how the Android networking stack has evolved over the years, why zero round-trip time matters on mobile and what it's like to contribute to a network protocol specification (spoiler: it's TLS 1.3). Brush up on your networking knowledge and tune in for this new episode! For feedback, please reach out on Twitter at @insidefbmobile, Instagram at insidefbmobile or drop us an email at mobilepodcasts@fb.com. Topics discussed - https://www.reactiflux.com/transcripts/react-native-team/ - https://www.reddit.com/r/reactnative/comments/av7vw3/future_ama_the_react_native_team_will_be_hosting/ - https://github.com/react-native-community/discussions-and-proposals/issues/64#issuecomment-446098249 - https://facebook.github.io/react-native/blog/2019/03/01/react-native-open-source-update - https://code.fb.com/developer-tools/mark-harman-harlan-d-mills-award/ Timestamps Intro 00:00 News 00:16 React Native OSS Update 00:25 React AMA 00:54 Relay 3.0 01:25 Sapienz 01:39 The Diff 02:40 Magma 03:22 Interview Prelude 04:03 Subodh Intro 05:02 First Projects 06:02 What got you interested in security? 07:18 Whitehat 08:15 FB Android networking 6 years ago 09:49 HTTPS enforcement 11:09 Evolution of the mobile networking stack 12:08 Certificate Pinning 15:07 Adopting system-level APIs 18:00 WebView security 20:29 TLS 1.3 features 21:32 Encrypted SNI 25:44 What's next after TLS 1.3? 27:46 Header compression flaws 28:34 QUIC 31:19 Standards Contributions (link) 40:07 mvfst 43:00 Low-level API UX 48:50 Katran: https://code.fb.com/open-source/open-sourcing-katran-a-scalable-network-load-balancer/ 52:20 Wrap-up 54:11 Outro 55:19 Bloopers 58:52  

Will Silicon Valley really stop death? Is Stoicism a healthy philosophy? Plus, the Microsoft Surface Go, and much, much more… Co-Hosts: N/A Opening Audio: N/A The Foreplay:--The Sovryn Tech Newsletter (zog.email), Microsoft Surface Go (bit.ly/2ztK5F2), Firefox Notes (bit.ly/2us4c0B),Firefox Focus switching from WebView to Gecko (bit.ly/2Jgl6F9),Google Podcasts app out now (bit.ly/2uu0fZk), Android Messages web interface available (bit.ly/2NaMoPy), AsteroidOS 1.0 is out (bit.ly/2NIgDOJ). Story of the Week:--"Silicon Valley’s Latest Lifehack: Death" Link: bit.ly/2uG69HR APPENDIX: -- Sovryn Tech Store:store.sovryntech.com--“ZenCash” Link: zensystem.io/ --"Roberts & Roberts Brokerage" Link: rrbi.co--"CryptoCompare" Link: www.cryptocompare.com/--“Unixstickers” Link: stickers.sovryntech.com--"Surveillance Self-Defense" Link: ssd.eff.org/ --"That One Privacy Site" Link: thatoneprivacysite.net/ --"Privacytools.io" Link: www.privacytools.io/ --"ipleak.net" Link: ipleak.net/ --"Secure Messaging Apps" Link: www.securemessagingapps.com/ --"A Graduate Course in Applied Cryptography" Link: toc.cryptobook.us/ --"URLscan.io" Link: urlscan.io/ --"WinZec Zcash Wallet" Link: winzec.com/--"EFF Guide to the US Border" Link: bit.ly/2m79lGe--"RetroShare" Link: retroshare.net/--“Books of Liberty” Link: booksofliberty.com/--"Dark Android: 2017 Edition" Link: darkandroid.info-------------------------------------------------------------------------------------Make easy monthly donations through Patreon: patreon.com/sovryntech Donate with Crypto! BTC: 1AEiTkWiF8x6yjQbbhoU89vHHMrkzQ7o8d ZenCash Shielded (encrypted) Address: zceDc5yyR5wY5w9ArxhAvLxWz2gpKMESTzC3iwzASong3o4oVgqp1VkZU1eeMUobPW87TStRABqcfN3rPSErFwyFnU8AjJeZenCash Transparent (unencrypted) Address: znZCyUwzGt19KqhCVzeR5iiUG5CEjNoe1YpZcash Shielded (encrypted) Address: zcfUhN29ddFdtZ1iKvv6WFFXUB9nKWwL5kXvcrvhQuB2yMw6eabshv1CGN92kkbtRt1Ykf1k2266sJvZAQQUrhmpuCwXUDD Zcash Transparent (unencrypted) Address: t1ZAA33YYzPmm4Ks5aq13N4NJBjqqSypY8G Donate with PayPal! Link: donate.zog.ninja Donate with our Amazon Wish List! Link: wishlist.zog.ninja -------------------------------------------------------------------------------------You can e-mail the show at: bbs@sovryntech.com-------------------------------------------------------------------------------------You can also visit our IRC channel on Freenode: #SovNet Or just go to: irc.zog.ninja -------------------------------------------------------------------------------------sovryntech.com twitter.com/sovryntech

Will Silicon Valley really stop death? Is Stoicism a healthy philosophy? Plus, the Microsoft Surface Go, and much, much more… Co-Hosts: N/A Opening Audio: N/A The Foreplay:--The Sovryn Tech Newsletter (zog.email), Microsoft Surface Go (bit.ly/2ztK5F2), Firefox Notes (bit.ly/2us4c0B),Firefox Focus switching from WebView to Gecko (bit.ly/2Jgl6F9),Google Podcasts app out now (bit.ly/2uu0fZk), Android Messages web interface available (bit.ly/2NaMoPy), AsteroidOS 1.0 is out (bit.ly/2NIgDOJ). Story of the Week:--"Silicon Valley’s Latest Lifehack: Death" Link: bit.ly/2uG69HR APPENDIX: -- Sovryn Tech Store:store.sovryntech.com--“ZenCash” Link: zensystem.io/ --"Roberts & Roberts Brokerage" Link: rrbi.co--"CryptoCompare" Link: www.cryptocompare.com/--“Unixstickers” Link: stickers.sovryntech.com--"Surveillance Self-Defense" Link: ssd.eff.org/ --"That One Privacy Site" Link: thatoneprivacysite.net/ --"Privacytools.io" Link: www.privacytools.io/ --"ipleak.net" Link: ipleak.net/ --"Secure Messaging Apps" Link: www.securemessagingapps.com/ --"A Graduate Course in Applied Cryptography" Link: toc.cryptobook.us/ --"URLscan.io" Link: urlscan.io/ --"WinZec Zcash Wallet" Link: winzec.com/--"EFF Guide to the US Border" Link: bit.ly/2m79lGe--"RetroShare" Link: retroshare.net/--“Books of Liberty” Link: booksofliberty.com/--"Dark Android: 2017 Edition" Link: darkandroid.info-------------------------------------------------------------------------------------Make easy monthly donations through Patreon: patreon.com/sovryntech Donate with Crypto! BTC: 1AEiTkWiF8x6yjQbbhoU89vHHMrkzQ7o8d ZenCash Shielded (encrypted) Address: zceDc5yyR5wY5w9ArxhAvLxWz2gpKMESTzC3iwzASong3o4oVgqp1VkZU1eeMUobPW87TStRABqcfN3rPSErFwyFnU8AjJeZenCash Transparent (unencrypted) Address: znZCyUwzGt19KqhCVzeR5iiUG5CEjNoe1YpZcash Shielded (encrypted) Address: zcfUhN29ddFdtZ1iKvv6WFFXUB9nKWwL5kXvcrvhQuB2yMw6eabshv1CGN92kkbtRt1Ykf1k2266sJvZAQQUrhmpuCwXUDD Zcash Transparent (unencrypted) Address: t1ZAA33YYzPmm4Ks5aq13N4NJBjqqSypY8G Donate with PayPal! Link: donate.zog.ninja Donate with our Amazon Wish List! Link: wishlist.zog.ninja -------------------------------------------------------------------------------------You can e-mail the show at: bbs@sovryntech.com-------------------------------------------------------------------------------------You can also visit our IRC channel on Freenode: #SovNet Or just go to: irc.zog.ninja -------------------------------------------------------------------------------------sovryntech.com twitter.com/sovryntech

On this LAB Radio, episode Aaron Mangal and Chris Groshong talk security, the Internet and origin story of how MetaCert helps protect users from malicious links with CEO and founder, Paul Walsh. Paul Walsh, CEO and founder of MetaCert and co-founder of W3C Mobile Web Initiative Paul is an early web pioneer in security and safety for users having helped create projects like the W3C Mobile Web Initiative who's mission includes "ensuring that the Web be available on as many kind of devices as possible". He also helped create standards and classifications for Uniform Resource Locations (URLs) as a part of his work at the W3C organization. "I'm CEO of MetaCert. In 2017 we completely eradicated phishing on Slack for the crypto world. In 2018 we pretty much brought a stop to phishing for the crypto world on Telegram. 2019 is going to be our most important year - our mission is to eradicate phishing for everyone who uses our new email security solution for native mobile email. Previously... I was part of the team that helped to launch technologies such as AIM, Internet Radio, Online Games and X2 56K Modem Protocol while working at AOL during the 90's. I co-instigated the creation of the W3C Standard for URL Classification/Content Labeling and I'm one of the seven original Founders of the W3C Mobile Web Initiative. I also own a full patent for Malware and Phishing detection and prevention inside a mobile app WebView with more pending. I own an Indian restaurant in Ireland - Michelin Star for 10+ years. [I am a] Irish. Father. Wine Drinker. Advanced Open Water Diver, Snowboarder, Skydiver Wannabe and Seasoned Traveller." -Paul Walsh This new broad access of the web we are seeing today has brought new challenges such as malicious individuals who seek to steal peoples data and even worse Cryptocurrency and the value within. The MetaCert team began by providing authenticity and monitoring of social media channels like Telegram and Slack which has a wave of malicious bot attacks on users, encouraging them to click on compromised links and put their sensitive data into fake websites which ultimately leads to theft. MetaCert aims to protect businesses from malicious threats and unsafe URLs inside Messaging Apps MetaCert has a patented enterprise-grade security API which can lookup over 2,000 shortening services and check it against a massive database of 10 billion classified URLs across 65 categories in a fraction of a second. MetaCert boasts the biggest threat intelligence system on the planet. The second to them is OpenDNS (run by Cisco) which has classified 2 million domains across 60 categories. One of the reasons for building its own threat intelligence system was to prevent false positives (which is a problem with current solutions on the market automatically blocking too many innocent sites). MetaCert recently released a beta of their email security solution which helps verify the safety of links: After listening to this episode you will learn: How Paul was an early semantic web pioneer in the 90s and created the W3C Mobile Web Initiative Why Paul felt websites and search engines should show more metadata and have an identity certificate What a Universal Resource Identifier (URI) is and why they are important How Webview works and was a vulnerability in our mobile use of the Web Why they got a patent in place for security around Webview to protect themselves from tech giants like Google Why the first iteration of MetaCert was for child safety and built a database for pornographic content How MetaCert saw the opportunity to organize and classify URIs and created the biggest Cyber Threat Intelligence Database to date How the MetaCert API works How MetaCert leverages a reward system for compensating people (Validators) for helping identify and log links Why the MetaCert "Green Shield" icon has become a pillar in their branding and marketing to the public Paul's vision for decentralizing governance around content, link filtering and working group/committee creation A fake news identifying browser add-on called TrustedNews which is 100% powered by MetaCert About how Paul is considering moving away from Ethereum (first time mentioned in public) For show notes and more visit: LAB Radio Episode 49

Peter Lisoskie is an accomplished Senior Executive and Innovator with more than 30 years of success across high-tech and product development. He holds 12 patents. Mr. Lisoskie has held leadership positions at companies as Division Manager for Hewlett Packard, VeriFone, and Nike he helped develop over 100 new products. While at Nike, he led the division in the development of one of the first Virtual Reality glasses in the world. Peter's industry experience includes bioscience, biomedical, consumer products, computer hardware, and test and measurement industries. Peter currently runs inViral Business Incubator and is CEO of BOT//NATION, innovating a new technology called Active Attention Design (A2D™). His software and data science teams are developing AutoIntelligent Bots™ utilizing artificial intelligence, neuroscience, Webview technology, databases, progressive web applications, predictive modeling, blockchain, and microservices. Visit Chat Bot Nation: Captivate Your Audience Using Interactive Conversational Chatbot Experiences

JSJ 268 Building Microsoft Office Extensions with Javascript with Tristan Davis and Sean Laberee This episode is live at the Microsoft Build 2017 with Charles Max Wood and AJ O’Neal. We have Tristan Davis and Sean Laberee from the Office Team at Microsoft. Tune in and learn more about what’s new with Microsoft Office Extensions! [00:01:25] – Introduction to Tristan Davis and Sean Laberee Tristan Davis and Sean Laberee are Program Managers on the Microsoft Office team, focused on Extensibility. Questions for Tristan and Sean [00:01:45] – Extending Office functionality with Javascript Office isn’t just an application on Windows that runs on your PC. It is running on iPhone, iPad, Android tablet, and apps on the browser with Office Online. The team needs a new platform, add-ins, which allow you to build apps that run across all places. It’s HTML and Javascript. HTML for all the UI and a series of Javascript module calls for the document properties. Sometimes we call it OfficeJS. [00:03:20] – This works on any version of Office? It works on Office on Windows, Mac, Online and iPad. [00:03:55] – HTML and CSS suck on mobile? There are things that you’re going to want to do when you know you’re running on a mobile device. If you look at an add-in running on Outlook for iPhone, the developer does a lot of things to make that feel like part of the iPhone UI. Tristan believes that you could build a great add-in for Office using HTML and JavaScript. [00:05:20] – Are these apps written with JavaScript or you have a Native with WebView? Office itself is Native. All of it is Native code but the platform is very much web. The main piece of it is pointing at the URL. Just go load that URL. And then, you can also call functions in your JavaScript. [00:06:35] – Why would you do this? How does it work? The add-in platform is a way to help developers turn Word, Excel and PowerPoint into the apps that actually solve user’s business problems. The team will give you the tools with HTML and JavaScript to go and pop into the Word UI and the API’s that let you go manipulate the paragraph and texts inside of Word. Or in Excel, you might want to create custom formulas or visualizations. The team also let people use D3 to generate their own Excel charts. And developers want to extend Office because it’s where a lot of business workers spend their days 0 in Outlook, Teams, Word, Excel. [00:10:00] – How did this get delivered to them? There are 2 ways to get this delivered. One, there’s an Office Store. Second, if you go into Word, Excel, and PowerPoint, there’s a store button and you can see tons of integrations with partners. For enterprises, IT can deploy add-ins to the users’ desktops without having stress about deploying MSI’s and other software deployments that the web completely rids off. The add-ins make a whole lot of pain the past completely go away. [00:11:00] – Everybody in the company can use a particular plug-in by distributing it with Office? That’s right. You can go to Office 365 add-in experience. Here’s the add-in and you can to specific people or everyone who’s part of a group. For the developer’s perspective, if you have the add-in deployed to your client, you could actually push updates to the web service and your users get the updates instantly. It’s a lot faster turn-around model. [00:14:20] – What about conversations or bot integrations? There’s the idea of connectors at Teams. You can subscribe to this web book and it’ll publish JSON. When the JSON is received, a new conversation inside of Teams or Outlook will be created. For example, every time someone posts on Stack Overflow with one of the tags that team cares about, it posts on Outlook. It’s a great way to bring all the stuff. Rather than have 20 different apps that are shooting 20 different sets of notifications, it’s just all conversations in email, making do all the standard email things. And in the connector case, it’s a push model. The user could choose what notifications they want. You’d also learn things like bots. You can have bots in Teams and Skype. The users can interact with them with their natural language. [00:18:40] – How about authentication? As long as you’re signed into Office, you can call JavaScript API to give you an identity token for the sign in user and it will hand you a JWT back. That’s coming from Azure Active Directory or from whatever customer directory service. That’s standard. If you want to do more, you can take that identity token and you can exchange that for a token that can call Microsoft graph. This app wants to get access to phone, are you okay with that? Assuming the user says yes, the user gets a token that can go and grab whatever data he wants from the back-end. [00:20:00] – Where does it store the token? That’s up to the developer to decide how they want to handle that but there are facilities that make sure you can pop up a dialog box and you can go to the LO-flow. You could theoretically cache it in the browser or a cookie. Or whatever people think is more appropriate for the scenario. [00:20:55] – What does the API actually look like from JavaScript? If you’re familiar with Excel UI, you can look at Excel API. It’s workbook.worksheets.getItem() and you can pass the name of the worksheet. It can also pass the index of the worksheet. [00:22:30] – What’s the process of getting setup? There’s a variety of options. You can download Office, write XML manifest, and take a sample, and then, side loads it into Office. You can also do that through web apps. There’s no install required because you can go work against Office Online. In the Insert menu, there’s a way to configure your add-ins. There’s upload a manifest there and you can just upload the XML. That’s going to work against whatever web server you have set up. So it’s either on your local machine or up in the cloud. It’s as much as like regular web development. Just bring your own tools. [00:24:15] – How do you protect me as a plug-in developer? There’s an access add-in that will ask your permission to access, say, a document. Assume, they say yes, pipes are opened and they can just go talk to those things. But the team also tries to sandbox it by iframes. It’s not one page that has everybody’s plug-ins intermingle that people can pole at other people’s stuff. [00:27:20] – How do you support backward compatibility? There are cases where we change the behavior of the API. Every API is gated by requirement set. So if a developer needs access to a requirement set, he gets an aggregate instead of API’s that he can work with but it isn’t fixed forever. But it’s not at that point yet where we end up to remove things completely. In Office JS, we’ve talked about API’s as one JavaScript library but really, it’s a bootstrap that brings in a bunch of other pieces that you need. [00:30:00] – How does that work on mobile? Do they have to approve download for all components? You can download components by using the browser that the operating system gives. It’s another one of the virtues of being based on the web. Every platform that has a web browser can have JavaScript execution run-time. It allows for the way that their app guidelines are written. [00:33:15] – How about testing? It’s a place where there’s still have work to do. There’s a bunch of open-source projects that partners have started to do that. What they’ve done is they’ve built a testing library. Whatever the mock is, it's just a thing on Github. It is open-source friendly. So the team could be able to contribute to it. “Here’s an interesting test case for this API. I want to make sure that it behaves like this. [00:35:50] – Could you write it with any version for JavaScript e.g. TypeScript? A Huge chunk of the team is big TypeScript fans. They’ve done a lot of work to make sure that TypeScript experience is excellence. Type is basically a collection of typing files for TypeScript. There’s a runtime process that parses your TypeScript, gives you feedback on your code, and checks for errors. You can also run it in the background. There’s an add-in called Script Lab. Script Lab is literally, you hit the code button and you get a web IDE right there. You can go start typing JavaScript code, play with API’s, and uses TypeScript by default. It’ll just actually load your code in the browser, executes, and you can start watching. [00:39:25] – Are there any limitations on which JavaScript libraries you can pull in? There a no limitations in place right now. There are partners that use Angular. There are partners that are big React fans. If you’re a web dev, you can bring whatever preferences around frameworks, around tools, around TypeScript versus JavaScript. [00:45:20] – What’s the craziest thing you’ve seen done with this API? Battleship was pretty cool. There’s also Star Wars entering credits theme for PowerPoint. [00:46:40] – If a developer is building a plug-in and get paid for it, does Microsoft take credit for that? There are 2 ways that folks can do it. You can do paid add-ins to the store. Either you do the standard perpetual 99 cents or you can do subscriptions, where it’s $2.99/month. Tristan encourages that model because integrations are just a piece of some larger piece of software. But Microsoft is not in the business of trying to get you to pay me a little bit of 10 cents a dollar. It’s really in the business of making sure that you can integrate with Office as quickly as possibly can. When the users go to the store, they can use the same Microsoft account that you use to buy Xbox games or movies in the Xbox, Windows apps in the Windows store. [00:52:00] – The App Model If folks are interested in the app model, they should go to dev.office.com to learn more about it because that’s where all the documentation is. Check out our Github. Right there in the open, there’s the spec. Literally, the engineers who are coding the product are reading the same marked-down files in the same repo that you, as a developer, can come and look at. And you can comment. You can add issues like you could have a dialogue with that PM. Under the OfficeDev, you’ll find a tunnel repository that contains samples. Our docs are there. Picks AJ O'Neal Lithium Charles Max Wood Miracle Morning by Hal Erod Clean Code by Uncle Bob Martin Ketogenic diet Tristan Davis Amazon Echo Microbiome Sean Laberee Running Garmin watch

JSJ 268 Building Microsoft Office Extensions with Javascript with Tristan Davis and Sean Laberee This episode is live at the Microsoft Build 2017 with Charles Max Wood and AJ O’Neal. We have Tristan Davis and Sean Laberee from the Office Team at Microsoft. Tune in and learn more about what’s new with Microsoft Office Extensions! [00:01:25] – Introduction to Tristan Davis and Sean Laberee Tristan Davis and Sean Laberee are Program Managers on the Microsoft Office team, focused on Extensibility. Questions for Tristan and Sean [00:01:45] – Extending Office functionality with Javascript Office isn’t just an application on Windows that runs on your PC. It is running on iPhone, iPad, Android tablet, and apps on the browser with Office Online. The team needs a new platform, add-ins, which allow you to build apps that run across all places. It’s HTML and Javascript. HTML for all the UI and a series of Javascript module calls for the document properties. Sometimes we call it OfficeJS. [00:03:20] – This works on any version of Office? It works on Office on Windows, Mac, Online and iPad. [00:03:55] – HTML and CSS suck on mobile? There are things that you’re going to want to do when you know you’re running on a mobile device. If you look at an add-in running on Outlook for iPhone, the developer does a lot of things to make that feel like part of the iPhone UI. Tristan believes that you could build a great add-in for Office using HTML and JavaScript. [00:05:20] – Are these apps written with JavaScript or you have a Native with WebView? Office itself is Native. All of it is Native code but the platform is very much web. The main piece of it is pointing at the URL. Just go load that URL. And then, you can also call functions in your JavaScript. [00:06:35] – Why would you do this? How does it work? The add-in platform is a way to help developers turn Word, Excel and PowerPoint into the apps that actually solve user’s business problems. The team will give you the tools with HTML and JavaScript to go and pop into the Word UI and the API’s that let you go manipulate the paragraph and texts inside of Word. Or in Excel, you might want to create custom formulas or visualizations. The team also let people use D3 to generate their own Excel charts. And developers want to extend Office because it’s where a lot of business workers spend their days 0 in Outlook, Teams, Word, Excel. [00:10:00] – How did this get delivered to them? There are 2 ways to get this delivered. One, there’s an Office Store. Second, if you go into Word, Excel, and PowerPoint, there’s a store button and you can see tons of integrations with partners. For enterprises, IT can deploy add-ins to the users’ desktops without having stress about deploying MSI’s and other software deployments that the web completely rids off. The add-ins make a whole lot of pain the past completely go away. [00:11:00] – Everybody in the company can use a particular plug-in by distributing it with Office? That’s right. You can go to Office 365 add-in experience. Here’s the add-in and you can to specific people or everyone who’s part of a group. For the developer’s perspective, if you have the add-in deployed to your client, you could actually push updates to the web service and your users get the updates instantly. It’s a lot faster turn-around model. [00:14:20] – What about conversations or bot integrations? There’s the idea of connectors at Teams. You can subscribe to this web book and it’ll publish JSON. When the JSON is received, a new conversation inside of Teams or Outlook will be created. For example, every time someone posts on Stack Overflow with one of the tags that team cares about, it posts on Outlook. It’s a great way to bring all the stuff. Rather than have 20 different apps that are shooting 20 different sets of notifications, it’s just all conversations in email, making do all the standard email things. And in the connector case, it’s a push model. The user could choose what notifications they want. You’d also learn things like bots. You can have bots in Teams and Skype. The users can interact with them with their natural language. [00:18:40] – How about authentication? As long as you’re signed into Office, you can call JavaScript API to give you an identity token for the sign in user and it will hand you a JWT back. That’s coming from Azure Active Directory or from whatever customer directory service. That’s standard. If you want to do more, you can take that identity token and you can exchange that for a token that can call Microsoft graph. This app wants to get access to phone, are you okay with that? Assuming the user says yes, the user gets a token that can go and grab whatever data he wants from the back-end. [00:20:00] – Where does it store the token? That’s up to the developer to decide how they want to handle that but there are facilities that make sure you can pop up a dialog box and you can go to the LO-flow. You could theoretically cache it in the browser or a cookie. Or whatever people think is more appropriate for the scenario. [00:20:55] – What does the API actually look like from JavaScript? If you’re familiar with Excel UI, you can look at Excel API. It’s workbook.worksheets.getItem() and you can pass the name of the worksheet. It can also pass the index of the worksheet. [00:22:30] – What’s the process of getting setup? There’s a variety of options. You can download Office, write XML manifest, and take a sample, and then, side loads it into Office. You can also do that through web apps. There’s no install required because you can go work against Office Online. In the Insert menu, there’s a way to configure your add-ins. There’s upload a manifest there and you can just upload the XML. That’s going to work against whatever web server you have set up. So it’s either on your local machine or up in the cloud. It’s as much as like regular web development. Just bring your own tools. [00:24:15] – How do you protect me as a plug-in developer? There’s an access add-in that will ask your permission to access, say, a document. Assume, they say yes, pipes are opened and they can just go talk to those things. But the team also tries to sandbox it by iframes. It’s not one page that has everybody’s plug-ins intermingle that people can pole at other people’s stuff. [00:27:20] – How do you support backward compatibility? There are cases where we change the behavior of the API. Every API is gated by requirement set. So if a developer needs access to a requirement set, he gets an aggregate instead of API’s that he can work with but it isn’t fixed forever. But it’s not at that point yet where we end up to remove things completely. In Office JS, we’ve talked about API’s as one JavaScript library but really, it’s a bootstrap that brings in a bunch of other pieces that you need. [00:30:00] – How does that work on mobile? Do they have to approve download for all components? You can download components by using the browser that the operating system gives. It’s another one of the virtues of being based on the web. Every platform that has a web browser can have JavaScript execution run-time. It allows for the way that their app guidelines are written. [00:33:15] – How about testing? It’s a place where there’s still have work to do. There’s a bunch of open-source projects that partners have started to do that. What they’ve done is they’ve built a testing library. Whatever the mock is, it's just a thing on Github. It is open-source friendly. So the team could be able to contribute to it. “Here’s an interesting test case for this API. I want to make sure that it behaves like this. [00:35:50] – Could you write it with any version for JavaScript e.g. TypeScript? A Huge chunk of the team is big TypeScript fans. They’ve done a lot of work to make sure that TypeScript experience is excellence. Type is basically a collection of typing files for TypeScript. There’s a runtime process that parses your TypeScript, gives you feedback on your code, and checks for errors. You can also run it in the background. There’s an add-in called Script Lab. Script Lab is literally, you hit the code button and you get a web IDE right there. You can go start typing JavaScript code, play with API’s, and uses TypeScript by default. It’ll just actually load your code in the browser, executes, and you can start watching. [00:39:25] – Are there any limitations on which JavaScript libraries you can pull in? There a no limitations in place right now. There are partners that use Angular. There are partners that are big React fans. If you’re a web dev, you can bring whatever preferences around frameworks, around tools, around TypeScript versus JavaScript. [00:45:20] – What’s the craziest thing you’ve seen done with this API? Battleship was pretty cool. There’s also Star Wars entering credits theme for PowerPoint. [00:46:40] – If a developer is building a plug-in and get paid for it, does Microsoft take credit for that? There are 2 ways that folks can do it. You can do paid add-ins to the store. Either you do the standard perpetual 99 cents or you can do subscriptions, where it’s $2.99/month. Tristan encourages that model because integrations are just a piece of some larger piece of software. But Microsoft is not in the business of trying to get you to pay me a little bit of 10 cents a dollar. It’s really in the business of making sure that you can integrate with Office as quickly as possibly can. When the users go to the store, they can use the same Microsoft account that you use to buy Xbox games or movies in the Xbox, Windows apps in the Windows store. [00:52:00] – The App Model If folks are interested in the app model, they should go to dev.office.com to learn more about it because that’s where all the documentation is. Check out our Github. Right there in the open, there’s the spec. Literally, the engineers who are coding the product are reading the same marked-down files in the same repo that you, as a developer, can come and look at. And you can comment. You can add issues like you could have a dialogue with that PM. Under the OfficeDev, you’ll find a tunnel repository that contains samples. Our docs are there. Picks AJ O'Neal Lithium Charles Max Wood Miracle Morning by Hal Erod Clean Code by Uncle Bob Martin Ketogenic diet Tristan Davis Amazon Echo Microbiome Sean Laberee Running Garmin watch

JSJ 268 Building Microsoft Office Extensions with Javascript with Tristan Davis and Sean Laberee This episode is live at the Microsoft Build 2017 with Charles Max Wood and AJ O’Neal. We have Tristan Davis and Sean Laberee from the Office Team at Microsoft. Tune in and learn more about what’s new with Microsoft Office Extensions! [00:01:25] – Introduction to Tristan Davis and Sean Laberee Tristan Davis and Sean Laberee are Program Managers on the Microsoft Office team, focused on Extensibility. Questions for Tristan and Sean [00:01:45] – Extending Office functionality with Javascript Office isn’t just an application on Windows that runs on your PC. It is running on iPhone, iPad, Android tablet, and apps on the browser with Office Online. The team needs a new platform, add-ins, which allow you to build apps that run across all places. It’s HTML and Javascript. HTML for all the UI and a series of Javascript module calls for the document properties. Sometimes we call it OfficeJS. [00:03:20] – This works on any version of Office? It works on Office on Windows, Mac, Online and iPad. [00:03:55] – HTML and CSS suck on mobile? There are things that you’re going to want to do when you know you’re running on a mobile device. If you look at an add-in running on Outlook for iPhone, the developer does a lot of things to make that feel like part of the iPhone UI. Tristan believes that you could build a great add-in for Office using HTML and JavaScript. [00:05:20] – Are these apps written with JavaScript or you have a Native with WebView? Office itself is Native. All of it is Native code but the platform is very much web. The main piece of it is pointing at the URL. Just go load that URL. And then, you can also call functions in your JavaScript. [00:06:35] – Why would you do this? How does it work? The add-in platform is a way to help developers turn Word, Excel and PowerPoint into the apps that actually solve user’s business problems. The team will give you the tools with HTML and JavaScript to go and pop into the Word UI and the API’s that let you go manipulate the paragraph and texts inside of Word. Or in Excel, you might want to create custom formulas or visualizations. The team also let people use D3 to generate their own Excel charts. And developers want to extend Office because it’s where a lot of business workers spend their days 0 in Outlook, Teams, Word, Excel. [00:10:00] – How did this get delivered to them? There are 2 ways to get this delivered. One, there’s an Office Store. Second, if you go into Word, Excel, and PowerPoint, there’s a store button and you can see tons of integrations with partners. For enterprises, IT can deploy add-ins to the users’ desktops without having stress about deploying MSI’s and other software deployments that the web completely rids off. The add-ins make a whole lot of pain the past completely go away. [00:11:00] – Everybody in the company can use a particular plug-in by distributing it with Office? That’s right. You can go to Office 365 add-in experience. Here’s the add-in and you can to specific people or everyone who’s part of a group. For the developer’s perspective, if you have the add-in deployed to your client, you could actually push updates to the web service and your users get the updates instantly. It’s a lot faster turn-around model. [00:14:20] – What about conversations or bot integrations? There’s the idea of connectors at Teams. You can subscribe to this web book and it’ll publish JSON. When the JSON is received, a new conversation inside of Teams or Outlook will be created. For example, every time someone posts on Stack Overflow with one of the tags that team cares about, it posts on Outlook. It’s a great way to bring all the stuff. Rather than have 20 different apps that are shooting 20 different sets of notifications, it’s just all conversations in email, making do all the standard email things. And in the connector case, it’s a push model. The user could choose what notifications they want. You’d also learn things like bots. You can have bots in Teams and Skype. The users can interact with them with their natural language. [00:18:40] – How about authentication? As long as you’re signed into Office, you can call JavaScript API to give you an identity token for the sign in user and it will hand you a JWT back. That’s coming from Azure Active Directory or from whatever customer directory service. That’s standard. If you want to do more, you can take that identity token and you can exchange that for a token that can call Microsoft graph. This app wants to get access to phone, are you okay with that? Assuming the user says yes, the user gets a token that can go and grab whatever data he wants from the back-end. [00:20:00] – Where does it store the token? That’s up to the developer to decide how they want to handle that but there are facilities that make sure you can pop up a dialog box and you can go to the LO-flow. You could theoretically cache it in the browser or a cookie. Or whatever people think is more appropriate for the scenario. [00:20:55] – What does the API actually look like from JavaScript? If you’re familiar with Excel UI, you can look at Excel API. It’s workbook.worksheets.getItem() and you can pass the name of the worksheet. It can also pass the index of the worksheet. [00:22:30] – What’s the process of getting setup? There’s a variety of options. You can download Office, write XML manifest, and take a sample, and then, side loads it into Office. You can also do that through web apps. There’s no install required because you can go work against Office Online. In the Insert menu, there’s a way to configure your add-ins. There’s upload a manifest there and you can just upload the XML. That’s going to work against whatever web server you have set up. So it’s either on your local machine or up in the cloud. It’s as much as like regular web development. Just bring your own tools. [00:24:15] – How do you protect me as a plug-in developer? There’s an access add-in that will ask your permission to access, say, a document. Assume, they say yes, pipes are opened and they can just go talk to those things. But the team also tries to sandbox it by iframes. It’s not one page that has everybody’s plug-ins intermingle that people can pole at other people’s stuff. [00:27:20] – How do you support backward compatibility? There are cases where we change the behavior of the API. Every API is gated by requirement set. So if a developer needs access to a requirement set, he gets an aggregate instead of API’s that he can work with but it isn’t fixed forever. But it’s not at that point yet where we end up to remove things completely. In Office JS, we’ve talked about API’s as one JavaScript library but really, it’s a bootstrap that brings in a bunch of other pieces that you need. [00:30:00] – How does that work on mobile? Do they have to approve download for all components? You can download components by using the browser that the operating system gives. It’s another one of the virtues of being based on the web. Every platform that has a web browser can have JavaScript execution run-time. It allows for the way that their app guidelines are written. [00:33:15] – How about testing? It’s a place where there’s still have work to do. There’s a bunch of open-source projects that partners have started to do that. What they’ve done is they’ve built a testing library. Whatever the mock is, it's just a thing on Github. It is open-source friendly. So the team could be able to contribute to it. “Here’s an interesting test case for this API. I want to make sure that it behaves like this. [00:35:50] – Could you write it with any version for JavaScript e.g. TypeScript? A Huge chunk of the team is big TypeScript fans. They’ve done a lot of work to make sure that TypeScript experience is excellence. Type is basically a collection of typing files for TypeScript. There’s a runtime process that parses your TypeScript, gives you feedback on your code, and checks for errors. You can also run it in the background. There’s an add-in called Script Lab. Script Lab is literally, you hit the code button and you get a web IDE right there. You can go start typing JavaScript code, play with API’s, and uses TypeScript by default. It’ll just actually load your code in the browser, executes, and you can start watching. [00:39:25] – Are there any limitations on which JavaScript libraries you can pull in? There a no limitations in place right now. There are partners that use Angular. There are partners that are big React fans. If you’re a web dev, you can bring whatever preferences around frameworks, around tools, around TypeScript versus JavaScript. [00:45:20] – What’s the craziest thing you’ve seen done with this API? Battleship was pretty cool. There’s also Star Wars entering credits theme for PowerPoint. [00:46:40] – If a developer is building a plug-in and get paid for it, does Microsoft take credit for that? There are 2 ways that folks can do it. You can do paid add-ins to the store. Either you do the standard perpetual 99 cents or you can do subscriptions, where it’s $2.99/month. Tristan encourages that model because integrations are just a piece of some larger piece of software. But Microsoft is not in the business of trying to get you to pay me a little bit of 10 cents a dollar. It’s really in the business of making sure that you can integrate with Office as quickly as possibly can. When the users go to the store, they can use the same Microsoft account that you use to buy Xbox games or movies in the Xbox, Windows apps in the Windows store. [00:52:00] – The App Model If folks are interested in the app model, they should go to dev.office.com to learn more about it because that’s where all the documentation is. Check out our Github. Right there in the open, there’s the spec. Literally, the engineers who are coding the product are reading the same marked-down files in the same repo that you, as a developer, can come and look at. And you can comment. You can add issues like you could have a dialogue with that PM. Under the OfficeDev, you’ll find a tunnel repository that contains samples. Our docs are there. Picks AJ O'Neal Lithium Charles Max Wood Miracle Morning by Hal Erod Clean Code by Uncle Bob Martin Ketogenic diet Tristan Davis Amazon Echo Microbiome Sean Laberee Running Garmin watch

Nolan Lawson a PM at Microsoft Edge joins us today to talk about PouchDB a popular open source project he's a maintainer of. PouchDB is an open-source JavaScript database inspired by Apache CouchDB that is designed to run well within the browser. In this episode we get into what PouchDB is good at and what type of projects would benefit from using PouchDB for their persistence layer (turns out, many!). PouchDB is framework agnostic but plays very well with many popular frameworks and libraries. Nolan gets into the performance of PouchDB and also what storage mechanisms it supports which include IndexedDB, WebSQL, LevelDB and many more. The episode takes a very unexpected turn leaving Justin, Danny and Leon wrapping up with some of their own PouchDB experiences. Resources https://pouchdb.com nolan lawson blog The cost of small modules IndexedDB, WebSQL, LocalStorage – what blocks the DOM? PouchDB custom builds PouchDB: a better build system with Rollup PouchDB map/reduce pouchdb-find PouchDB replication Around the Web in Two Minutes Friday 10th March - Password Rules are BS Co-founder of Stack Overflow Jeff Atwood publishes an article raging about how stupid password rules are. Very insightful article TLDR; Just use a long password, it's totally fine to use memorable words as long as it's long enough https://blog.codinghorror.com/password-rules-are-bullshit/ Wednesday 15th March - Chrome 57 throttles background tabs to increase battery life http://www.theverge.com/2017/3/15/14932718/google-chrome-browser-battery-life-tab-throttling Tuesday 21st March - Mozilla Proposes “Obsidian” Web Graphics API Obsidian is a low-level API intended to provide a maximum feature set of the GPU to web applications. Similar to Vulkan, it's designed for WebAssembly, modern GPUs, and a multi-threaded environment. https://www.gamedev.net/news/index.html/_/programming/mozilla-proposes-obsidian-web-graphics-api-r62 Tuesday 21st March - Android O Announced Multi-process mode for WebView is enabled by default and API to let your app handle errors and crashes https://android-developers.googleblog.com/2017/03/first-preview-of-android-o.html The “Option to mark an event listener to fire only once” feature is now under development in Microsoft Edge https://developer.microsoft.com/en-us/microsoft-edge/platform/status/eventlisteneronceoption/?q=event%20listener Guests Nolan Lawson (@nolanlawson) Panel Danny Blue (@dee_bloo) Leon Revill (@RevillWeb) Justin Ribeiro (@justinribeiro)    

ControlTalk NOW — Smart Buildings VideoCast|PodCast for week ending August 28, 2016 — Is aptly referred to this week as “The Show that Almost Was,” because of travel constraints and preparations for the 2016 CTA Awards. Still, we are able to present an abbreviated time-lapse preview of the ControlTrends People, a new PodCast series that focuses on the life stories of the people in our industry that make it great. Special thanks to Tridium’s Jenny Graves, Nino DiCosmo, Pranay Prakash, John Sublett and Ed Merwin for their hospitality and support. Also, this week, Contemporary Controls’ introduced their new EIA-485 Terminator; an Updated Ken’s Calendar; and a Heads-up on two important Webinars: Belimo’s Webview and OPTIGO Networks’ Visual BACnet. CTN 193 The Show That almost Was from Eric Stromquist on Vimeo. Contemporary Controls’ New EIA-485 Terminator Provides Fail-Safe Biasing for BACnet MS/TP and Modbus RTU Networks. New EIA-485 Terminator Provides Fail-Safe Biasing for BACnet MS/TP and Modbus RTU Networks. Contemporary Controls‘ 485-TER is a standalone active terminator that is used on popular EIA-485 networks such as Modbus RTU and BACnet MS/TP providing sufficient termination and biasing for stable operation. Fail-safe bias ensures that an un-driven line assumes a defined state. ControlTrends Keeps an Eye on 2016 Events with Ken’s Calendar. While it has been an amazingly busy and productive year so far, many more events are on the horizon. ControlTrends will continue to post the event information as we receive notice or become aware of the event. Please note that the information is gathered from various sources, and the times, dates, and locations may have changed. Be sure to visit the appropriate website or contact the event coordinator to ensure the most up-to-date information. Belimo — Communicating with the Energy Valve through WebView, the New Data Analysis Tool, and BACnet Webinar. Join us for a 30 minute webinar on the communication features of the Belimo Energy Valve. We will review connecting to the Energy Valve’s web server TCP/IP from a laptop or PC and discuss how to download data files using the New Belimo Data Analysis Tool. You will also learn how to use the Belimo ZTH US tool to easily adapt the flow settings of the Energy Valve as well as information on the BACnet features of the Energy Valve will be discussed. OPTIGO Webinar: Troubleshooting BACnet in Wireshark — Featuring Steve Karg, Sep 8th, 2016, 11AM PST. Not sure what is happening in your building network? Dealing with poor network performance? Use Wireshark, a free network packet analyzer, to dig into the network traffic to uncover the root cause of the issue. Wireshark is a free network packet analyzer that helps troubleshooting by capturing network packets and allowing you to browse the network traffic to isolate the issues in a network. OPTIGO Networks provides advanced visualization tools to help you gain insight into the health of your BAS deployments. The post ControlTalk NOW — Smart Buildings VideoCast|PodCast for Week Ending August 28, 2016 appeared first on ControlTrends.

01:04 - Ryan J. Salva Introduction Twitter GitHub Blog 02:08 - Cordova WebView 05:19 - Hybrid; Native Applications 11:58 - Code Reuse and Sharing 16:01 - Performance 25:32 - Update 29:36 - Performance (Cont’d) 37:11 - The Development Process   Picks Microsoft Bot Framework (Ryan) Ryan's Blog (Ryan)

01:04 - Ryan J. Salva Introduction Twitter GitHub Blog 02:08 - Cordova WebView 05:19 - Hybrid; Native Applications 11:58 - Code Reuse and Sharing 16:01 - Performance 25:32 - Update 29:36 - Performance (Cont’d) 37:11 - The Development Process   Picks Microsoft Bot Framework (Ryan) Ryan's Blog (Ryan)

Richard, Chet, Ben, and not Tor in the spacious London studioIn this Tor-less episode, Chet talks with Ben Murdoch and Richard Coles from the Android WebView team. We talk about WebView's ability to update outside of platform releases, the transition from the original WebView to the new Chromium WebView widget, about some of the new features and APIs in recent releases, and about cute kitten bitmaps.Tor didn't have much to say, about kittens or anything else.Subscribe to the podcast feed or download the audio file directly.Relevant LinksBeta Channel for Android WebViewGoogle+ Beta Channel CommunityBug TrackerChrome Dev ToolsWebView APIBen Murdoch: google.com/+BenMurdoch, @ksasqRichard Coles: google.com/+RichardColesGoogleTor: google.com/+TorNorbye, @tornorbyeChet: google.com/+ChetHaase, @chethaaseAlso, thanks to continued support by Bryan Gordon, our audio engineer who puts this stuff together every time.

Novos termos de uso do Facebook; Google não vai corrigir WebView para Android; Ministério Público no encalço da TIM; Foxconn vai demitir funcionários; Resultados da Microsoft; Xiaomi Mi Note esgota em 3 minutos.

Cette séquence présente la construction d'application web via Android.

Hajime Morrita さんをゲストに迎えて、WebKit, Chrome, WebView, リファクタリング, Rx などについて話しました。 Show Notes PushBullet Rebuild channel steps to phantasien WebKit Quest Blink - The Chromium Projects WebComponents.org Shadow DOM 101 - HTML5 Rocks Service Workers A Beginner's Guide to Using the Application Cache - HTML5 Rocks Google Gears Background Pages - Google Chrome Safari Push Notifications - Apple Developer Android 4.4+ KitKat ships without browser app. OEMs have to license Chrome or build their own Lollipop unwrapped: Chromium WebView will update via Google Play WKWebView Class Reference Link Bubble - mobile browsing done right Javelin browser 書類仕事を追いかけて Inside Google's culture of relentless self-surveying リファクタリング The reactive manifesto Akka JavaScript Promises: There and back again - HTML5 Rocks Finagle Reactive Extensions ReactiveX/RxJava ReactiveX ReactiveCocoa for a better world ReactiveX/RxAndroid Netflix JavaScript Talks - Async JavaScript with Reactive Extensions #10 node.js sideshow | mozaic.fm Erik Meijer (@headinthebox) | Twitter

@iizukakと@h13i32maruの二人でWebフロントエンドを中心とした話をしました。 寿司との最適な距離の取り方につ Firefox OS AngularJS Vim Advent Calendar 2012 PhpStorm JavaScript - Client Side - Advent Calendar 201 Firefox OS Advent Calendar 2013 Next Mobile WebApplication HOBBIT Web Audio API Can I use WebView for Android ExGame LWF High Webフロントエンドパフォーマンスチューニング Chrome Effectively skia MDN Knockout JavaScriptフロントエンド開発の昨今 ブログを書くまでがHTML5

本期由 Dingding Ye 主持，邀请了 RubyChina 的核心开发者之一和 Mac 版的作者 Ashchan 给大家分享了他在 Mac 桌面应用和 iOS/Android 移动开发上的一些心得体会。同时参与嘉宾有 Terry Tai。主要涉及内容有: 各种 Ruby Bridge/Binding for Mac/iOS dev Mobile Development including iOS and Android HTML based solution such as WebView, PhoneGap, Titanium and etc. 乐库科技 Rakuraku gmail-notifr RubyCocoa: A Ruby/Objective-C Bridge for Mac OS X with Cocoa MacRuby: Ruby for the Objective-C Runtime, an implementation of Ruby 1.9 directly on top of Mac OS X core technologies RubyMotion: Ruby for iOS, a revolutionary toolchain for iOS. Programming Cocoa with Ruby ARC PHP Addiction PhoneGap: A free and open source framework that allows you to create mobile apps using HTML, CSS and JavaScript. Titanium: An open, extensible development platform for creating beautiful native apps across different mobile devices and OSs including iOS, Android, Windows and BlackBerry, as well as hybrid and HTML5. jQuery Mobile: A unified, HTML5-based user interface system for all popular mobile device platforms, built on the rock-solid jQuery and jQuery UI foundation. iWeekly Mind Map Book MindNode Pro Echofon for Social RubyMotion 我是歌手 Special Guest: Ash Chan.

In this video, we'll add all of the pages to the Blog Reader, including the ItemsPage which lists all of the blogs, the SplitPage which lists all of the blogs posts for the selected blog, and the Detail page which shows the select blog post in a WebView control.Step-by-Step tutorial from dev.windows.com Blog Reader complete code

Full transcript for this screencast is available at http://www.karelia.com/sandvox/screencast_transcript.html This is the text for Chapter 1: A day in the life… Hello and welcome to this screencast Introduction to Sandvox, the powerful, playful and intuitive website creation application from Karelia Software. In this screencast I’ll be showcasing many of Sandvox's creative features. To get started, I’ll show what it's like in the "day in the life" of a Sandvox website. Here on the Desktop is my Sandvox document. Let’s open it. This is a website I’ll build from scratch later, one that recounts my family’s summer trip to Ireland. For now, to get an overview of how Sandvox works, let's add a new page, make some simple edits, and publish those changes. This main document window is how you'll work with most aspects of your site. At the top we have a standard Mac OS X toolbar with icons to help us add pages, create links, and so on. Here on the left hand side we have our Site Outline, which shows all the pages of my site; the home page is at the top. The rest of the window is the WebView, which shows us the content of whatever page we have selected in the Site Outline, just as it would look in the Safari web browser. The first thing I’ll do is edit the content of the “about” page, which explains the purpose of this site. I’ll select “About” in the Site Outline. Now it displays that page in the WebView. To start editing, I click on the area of the text I want to change. For this page I’ll just remove a paragraph, and add another in its place. Then I’ll work in some basic styling. I’ll select some text and make it bold by selecting “bold” from the Format menu Next, I'll add some hyperlinks. I want to link the word “pictures” to the photo album I created, so I highlight that text and click on "Create link" in the toolbar. A little panel opens up. If you want to link to another website, you would type or paste in a URL . But since I need this link to go to another page on my own site, I drag this target icon to the site outline, and connect it to the page I want to link to. To close the link panel I click in some other part of the window. Notice when I hover over that link, I see where it’s linked to, down on the status bar at the bottom of the window, just like in Safari. For my last edit, I’ll add an entry about my day trip to Blarney Castle to the weblog. A weblog can be thought of as an online journal; a collection of articles with the most recent entries at the top. Adding a new entry to an existing weblog is very easy to do. I’ll add a text page from the popup menu in the toolbar, and then type the entry directly into Sandvox. Now, with all of my editing done, I’m ready to publish, so I click on the publish icon in the toolbar. From Sandvox you can publish to any web host, or even your own computer. This site is already setup to upload to an FTP site. If you’re curious about publication settings, they will be reviewed in detail toward the end of this screencast. When uploading is finished, I can visit the site. There it is in Safari; and there are my changes. This covers what “a day in the life” of a Sandvox website is like. Over the next few chapters of this screencast we'll recreate this website in Sandvox from scratch, demonstrating how to: • Create a new site; • Manage content with pages, pagelets, and collections; • Add and manage a weblog as well as albums of photos and movies; • Setup publishing; • And look at some advanced features.