Coming up on DTNS, what Apple's VR headset might be like, Facebook's Supreme Court faces its big test and one messenger app to rule them all. This is the Daily Tech News for Thursday, January 21st, 2021 in Los Angeles. I'm Tom Marin. And from Studio Redwood, I'm Sarah Lane. From Oakland, California. I'm Justin Robert Young. And I'm the show's producer, Roger Chan. We were just talking about Super Bowls and sports and all kinds of cool stuff on good day internet. Get that longer, wider conversation. Become a member at patreon.com slash DTNS. Let's start with a few tech things you should know. The Raspberry Pi Foundation released a $4 microcontroller called the Raspberry Pi Pico. The first device using the foundation's own RP2040 dual core, 133 megahertz arm chip. The Pico microcontroller includes 264 kilobytes of RAM, 26 GPIO pins, a micro USB port and a temperature sensor. It can be programmed in C or micro Python. Samsung Display plans to release the first 90 Hertz OLED screens for laptops. Manufacturing begins in March in large quantities with, quote, several global IT companies expected to release models with the panel later this year. The initial panels will be 14 inches, though aspect ratio and resolutions were not announced. The security firm Corellium released a port of Ubuntu Linux to run on M1-based Macs. The OS boots into the full desktop interface and includes USB support, although there isn't any hardware acceleration and networking requires using a USB dongle. The Ubuntu build and tutorial to get it running are available on GitHub. Yeah, I had to use a dongle to get internet access when I ran Xandros on my Thinkpad back in 2004, so same thing. Google reached an agreement with APIG, a group representing about 300 political and general information press titles in France on a framework to pay the publishers for the reuse of snippets of content in compliance with the 2019 reform to copyright law. France's competition regulator ruled back in April that Google couldn't just not show snippets. It's against the law for them not to show snippets because that would be an abusive dominant market position and so ordered Google to negotiate payment terms. A non-tech note that Intel's incoming CEO, Pat Gelsinger, who takes over on February 15th, has already started making some moves. Retired Intel senior fellow Glenn Hinton, who was co-lead architect on the Nahalem CPU Core, is coming out of retirement to work on an exciting high-performance CPU project. Hinton said on social media that, quote, if it wasn't a fun project, I wouldn't have come back. As you know, retirement is pretty darn nice. Oh, look at Hinton. All right, let's talk about this big messenger thing. I'm so excited. OK, so if you harken back to the days of trillion, adium, pigeon, whatever you might have used to get a bunch of I am messaging services together in one place, instant messaging on the desktop, ruled conversations, remember those days? Well, then phones caught up and then lots of people move their conversations to WhatsApp or Line or WeChat or Signal or Telegram or iMessage or Hangouts or all of them. And now, if you're one of those people, you have to remember which person uses which app before you send them a message and make sure that you don't miss a message from that person. So if you remember Pebble, not a messaging app, that was the power efficient watch that worked with any device and had a battery that lasted days, also shut down December 7th, 2016, and then Fitbit bought the IP. OK, we're coming around, coming for a circle here. Pebble founder Eric Migikowski is now trying to solve the messenger problem for all of us and has launched something called Beeper, a universal chat app that promises to bring 15 different chat platforms into one single interface, but not for free for $10 a month. Beeper runs on Android, iOS, Windows, Mac OS, Linux. It can access 15 networks with more to come. But starting with the big ones, WhatsApp, Facebook, Messenger, Instagram, Android messages, Telegram, Twitter, Slack, Google Hangouts, Skype, IRC, Matrix, Discord, Signal, the Beeper network itself, and Apple's iMessage. Now that's turning some heads, right? Because Beeper promises to let you access iMessage on Android, Windows, and Linux. If you have a Mac, you install the Beeper Mac app, and then it acts as a bridge in order to get everything together. Some people might not have a Mac. If you don't have a Mac, Beeper supposedly has 50 iPhone 4s, jail broken already, and ready to send customers to act as the bridge. Now, okay, 50, that's a little bit silly, but it sounds like the company's saying, listen, we're trying to make sure that we are reaching people who want the service, even if you don't have all the required hardware. The rest is all done using the open source matrix messaging protocol to bridge all the gaps with Megakovsky, hoping it will lead to people using Matrix chat, so we don't all exist on separate networks. Now, I know this sounds like a utopia. Is it possible? It may very well appeal to you, but it's open by invitation only. If you are interested, you can go to BeeperHQ.com to learn more and get on that waiting list. That's why you can get by with only 50 iPhone 4s, because he just won't take too many invites, but that is a hang up, because that's not a sustainable thought to be sending people jail broken iPhone 4s, I don't think. But I don't want to dwell on that part. I want to distract myself and look at the promise of fixing this problem, where we all could just have one messaging app and we could choose our platform. We could all be on, you know, I could be on Signal, you could be on WhatsApp, but we could still somehow messaging each other through Beeper. That sounds great. Oh, yeah. I mean, I was a big trillion user back in the day when I kind of switched over from Windows to Mac OS. I hopped on Addium for years. I, most people really were using AOL Instant Messenger still at that point, but not everybody. It was really, really helpful. I, when I first heard the story, I was like $10 a month. Absolutely not. I mean, how hard is it to turn on notifications for various apps? I also really only have, let's say, three different platforms where I'm getting messages regularly that are really important to me. So sure, I can pledge notifications here and there if I want to, but I pulled some friends this morning like, Hey, Windows folks, is this interesting to you? And a couple of people were like, Oh my gosh, yes, you have no idea. This is very interesting to me, especially because I'm kind of sitting at my computer most of the day. And it can be sort of a mess. Also, another friend said, you know, the group text stuff, let's say WhatsApp, just as an example, he's on like 15 different group chats on WhatsApp. I am not. So I don't get the hellscape that it must be to be getting notifications when you really don't want to miss a message on something like that. And so sure, I can see we're having a central place where lots of content is coming in and you can manage it a little bit better and not have to just be pinged on your phone every five seconds is possibly worth the money. Yeah, I think this is an interesting idea. I don't know if this is the value proposition that it is positioning itself as. I do think it might be the future. However, specifically, as we look at a lot of these antitrust conversations that are coming down the pike and the fact that our walled garden chat ecosystem seems to be breaking down a little bit more than it has been in the past. The idea of all of these platforms being fed into something else, including Apple's iMessage, might be something that we see in the future. I don't know if it will happen via a third party app or if maybe Apple itself will have a new beefed up iMessage that will take advantage of a lot of these other platforms, APIs. I see people in the chat room saying like, I can get a desktop app for all the messaging apps I want to use. Why is this a big deal? Well, if that was the case, no one would have loved Trillion because you could have a desktop app for Yahoo Instant Messenger, MSN Messenger and AIM. It wasn't just I don't get notifications or I want to run three apps. It's fine. It was I want one place. I only want to think of one place. I don't want to have to remember like, oh, I'm messaging Sarah. Do I launch Yahoo or do I launch AIM? Which one do I need to have? You just want one place. That sounds to me like it might be worth $10 a month if it really works, which is a big if. I'd be willing to try this. I don't know if I would continue to use it. That remains to be said. All you need is one missed message because you decided to try to aggregate. Well, I messaged does that on its own anyway. Yeah. And and people get frustrated with that. Not that I mean, not that often. And listen, it used to be impossible to talk to anybody using an Android phone. It is now much easier. So we are inching toward some sort of more unified world. But yeah, I don't know, 10 bucks a month. Not for me, but anybody anybody who gets in there, let me know how it's going to change my life. You and your 49 friends with your jailbroken iPhones, Bloomberg's Mark Gurman sources say that Apple's first VR headset, codenamed N 301 may launch as early as 2022 and will operate as a standalone battery powered device running on its own power efficient chips. The size will reportedly be close to the Oculus Quest with a fabric exterior to save on weight and include a cooling fan. Some prototypes also include external cameras for AR features with Apple testing, hand tracking and virtual keyboards. The headset is expected to be an expensive device with some at Apple forecasting initial sales of less than 200,000 in the first year. Apple has about a thousand people working on AR and VR currently. Dang. Uh, yeah, some things to unpack anything that is Oculus Quest like because I have a quest. I have the original quest, not the quest to. So it's even a little bit bigger than than what Oculus is doing, but uh, I, it has brought me a lot of joy and I think that anybody who's understanding that form factor is going to be like, okay, yeah, this is dope. Having external cameras for some AR capabilities. Interesting to me. What would that look like?  Well, that would be for the sensors. You know, I would imagine that would be for like doing motion tracking, doing that, that kind of because you have external cameras on the Oculus as well. Yeah, that kind of like inside out tracking. Well, yeah, the quest to you can see through. And, and especially when you're setting your boundary at the beginning of play, you came with the original quest as well. I guess you're right, Sarah. The cameras are for AR features, so it's going to show you the outside room while you've got the headset on. Maybe, maybe, because I also think that if Apple is going to do this, considering how much time and effort that they've put into AR and they have used AR as a demo feature at every press conference for the last five years, it feels like I could see them looking to push this as more of a, especially in a work from home world, a slap it on your head. It's not just for gaming. It's also for productivity. You can leave it on. You can see through it. It can give you information in real time. And that's very Apple, isn't it?  It's like, that's not really Apple. Apple possibly selling a, I mean, if you're comparing it to iPhone sales, a pretty small number of these in the first year, that, you know, some people were like, oh gosh, that sounds pretty bad. There may be some supply chain issues. I mean, lots of companies are going through that right now. But this is also, it is a new form factor.   And I'm sure that Apple is taking a lot of that into consideration and the price point, very important because Apple historically makes very nice things and also prices. A lot of people out of those very nice things. Yeah, look, I love the Oculus Quest 2. I think it is a game changing device for VR in terms of its casual ability. I have begun most of my days over the last week playing putt-putt golf with my friends, Brian Brushwood and Andrew Heaton in the morning. We play 18 holes and BS and then just take off our headsets and get to our day. That is magic and fantastic. I love it. That being said, I loved my sidekick. And then the iPhone came out. And I don't want to take away from how important the sidekick was. I think the sidekick was, you know, if it weren't released in proximity to the iPhone, it would still be heralded as a massive game changer because it did bring an internet experience that was here to fore kind of unseen in terms of how you were designed to interact with it. This feels like the time when Apple senses a ripe, mature marketplace and decides to supercharge it with a lot of power and a lot of polish. Yeah. Two thoughts on the price, too, with the price in the sales. Apple Watch didn't sell very well at first until it started selling really well. And people thought it was too expensive early on. People definitely thought the iPhone was too expensive. When people forget, 2007, oh, yeah, I didn't get an iPhone for like two years. I was like, ridiculously expensive. Yeah. And and now people complain about the price still because people always complain about prices. But it is not necessarily that much or even more expensive than similar flagships. Yep. You know, the Apple Watch is a good example of this.  But then word gets out of like, oh, this is actually really helpful and hear all the reasons why. And then, you know, the company, of course, is iterating. The first Apple Watch is very different than the current Apple Watch, which has a lot more features. But the VR thing, Justin, I'm with you. I don't play a pep golf. Well, that sounds really fun. Should. But it's it's it really is. And I know I sound like a broken record sometimes and, you know, tell me to shut up. But it's like, you don't know how fun it is until you play around with it. And then you're like, oh, OK, I get it. I get how I get how cool this is. This Bloomberg story talks a lot about how this thing, they're having a hard time making it comfortable.  Take my money. Gosh, all right. Amazon Chief Executive of Worldwide Consumer Business, Dave Clark, sent a letter to the US president offering to help reach the goal of vaccinating 100 million people against COVID-19 in 100 days. Clark offered the leverage of the company's, quote, operations, information technology and communications capabilities to the effort, noting that Amazon has an agreement with a licensed healthcare provider to administer vaccines at its facilities. Amazon, however, is not taking part in the Washington State Vaccine Command and Coordination Center, although Starbucks, Costco and Microsoft are. The letter also made the case that essential workers at Amazon fulfillment centers, AWS data centers and Whole Foods market stores should get the vaccine early. In October, Amazon said more than 19,000 of its workers had tested positive for COVID out of its 1.13 million employees. That was back in October, so it's definitely higher now. Amazon is also expected to report its first $100 billion quarter on February 2nd. They've been making money during this pandemic. Amazon's also spending money. They spent $7.5 billion on COVID related costs in Q3. And they're expected to report another 4 billion of expenditures related to COVID in Q4. This is a fascinating developing situation for a couple of different reasons. Number one, without a question, Amazon is probably the world's leader in terms of logistics. They have by design from their earliest days put strategically close distribution centers so they could get you your products as fast as possible. That means that they have facilities and theoretically parking lots at the very minimum for which they could allow for vaccine administration. But speaking of administration, you can't not think about the fact that Amazon is almost assuredly and some, including myself, believe maybe the most open and shut case for antitrust. We have new leadership in Washington, D.C., a leadership that based on those that are currently employed there would seemingly have a more friendly relationship with big tech, including Amazon. And it is very interesting to see whether it be a PR play or something that could be used as a, well, look at who stood up when COVID raged and the vaccine needed to be distributed. Amazon stepped up in our era of invoking the Defense Production Act for private companies to do public good. They stepped up and did it. They didn't even have to be asked. There's there's a lot going on here. And I feel like we want to keep an eye on the relationship between big tech and the White House in general. And this is a huge step forward on that. Yeah. And you want to pick where you step up? The state of Washington only has one attorney general. If you help the federal government, you're helping the whole country. Yeah. Yeah. I don't know enough about the mechanisms of the state consortium because, you know, everything is local. But in terms of them doing it nationally, A, they're not wrong. They could probably do a lot of good in terms of distributing things as far as them getting their own people vaccinated first. That's a much larger question on exactly how much we want to wait, quote, unquote, essential workers over larger populations. If what we want to do is get as many people vaccinated as fast as possible. Well, folks, we want to know what you want to hear us talk about on the show. One way to let us know is our subreddit. Get in there, submit stories and vote on them at Daily Tech News Show dot reddit dot com. Facebook has referred its decision to indefinitely suspend President Donald J. Trump's account to the independent oversight board that it had set up last year. Facebook's Vice President of Global Affairs Nick Clegg said that the company believes the decision was right. But given criticisms by world leaders such as Chancellor Angela Merkel, the company thinks that it is quote important for the board to review and review it and reach an independent judgment on whether it should be upheld. A five member panel will take up the case and share findings with the full board. Majority approval will be needed on any decision that must be made within 90 days. The board will evaluate whether the content in question violated Facebook standards and whether the removal respected international human rights, including freedom of expression. Statement from the pages administrators can be submitted arguing why the suspension should be overturned and public comments will be taken. In the meantime, the suspension remains in place. Facebook will have up to seven days to implement a decision once it is published and 30 days to respond publicly to any policy change recommendations. Oh, this is this is the test case. We were talking when we were preparing for this show how we haven't heard anything about this oversight board. They've they've been working. They've been reviewing cases. But nothing has caught anyone's eye until this. And this is likely one of the biggest cases that this oversight board could possibly face because it's a world leader. And it certainly is the case that's going to set the precedent. How they deal with this is going to point this oversight board in a direction from now on. Without a doubt, I think that there is a massive, massive question that we have to ask ourselves right now. Will we respect this decision? No matter whether or not we agree or disagree with it. Well, Tom, you sort of made like a, you know, sort of a semi joke at the beginning of the show of it, you know, being like the Facebook Supreme Court. But really, if you think about it this way, it's, you know, the company saying, OK, we're, you know, we're getting into these kind of hot water situations. That's the whole idea of the independent oversight board. And yeah, you don't really hear much about the board. They are doing things. I'm sure there's plenty of stuff that would be very interesting to us that we just haven't heard of. This is just such a high profile decision that, yeah, you're going to get a lot of folks who, no matter what it is, who are happy or not happy with that. And will the oversight board be able to say, well, sorry, I mean, you can't go any higher than us. That's just the way it is.  Or will this become either something that, you know, makes people leave Facebook, which is unlikely, but sure, maybe a few, or say that the oversight board needs to have oversight. I think not only do is the public reaction to this important, but also if this does not come back in a way that Facebook likes, will Facebook even adhere to it, right? Because they have they have their own personal decision on how they take the ruling by the oversight board. Yeah. If Facebook doesn't implement the decision that then they should never have even bothered. So they have to they have to implement whatever decision. Now, the policy recommendation is where they have wiggle room. The policy recommendation isn't binding. The decision is supposed to be. Facebook is committed to whatever decision they say, leave it up, take it back down. We will follow. And if they don't do that, then yeah, this whole thing was a charade. If, however, they say you you can you can continue to do what you were doing. But we think in the future, you should change how you do it. That's where Facebook can go, OK, we'll take that under advisement. Fact of the matter is I already see people in our chat room saying this is bad. I don't know what else they could do, right? Short of having governments pass laws on what moderation decisions should happen, which you know, we have a whole section to 30 special about stuff like that. I just don't know. Facebook said, look, we'll set up an independent board. They get to choose their members. They make decisions, actual decisions we will follow. Like, you know, is it bad or is it I don't think they'll rule the way I think they should rule. So I think it's bad. That's and that is the question. That is the million dollar question. And there are very few ways that you can make everybody happy on this particular subject. Well, yeah, you can't make everyone happy because you have to make a decision. So the only the only way to win is not to play. But you know, that just leaves things the way they are. Yeah, people are mad about that, too. Yeah. Well, in 2015, Instacart hired some of its workers as employees. So they had to pay the extra payroll tax. So they cost more than than other employees that aren't full time employees that are contractors. When you have an employee, you have to offer protections like minimum wage. At the time, Instacart CEO approved of Mata said, quote, our shoppers require training and supervision, which is how you improve the quality of the picking. You can't do that when they are independent contractors. That was six years ago. That was 2015. 2021 Instacart thinks, well, we don't have to employ them. Somebody else could. And so Instacart has announced it will eliminate 1,877 employees, including 10 union workers in Illinois, which they can do because they're just eliminating the positions and is going to shift toward letting retailers use Instacart tech to have their own employees prepare orders. Instacart says it will attempt to place the 1,877 employees at partner retailers or elsewhere within Instacart where possible and they have severance packages for anybody that they can't place. Yeah, this is a this is an interesting story because okay, say I'm an Instacart worker. I am a freelance worker. I'm not on staff. I sounds like my job kind of continues because Instacart is working in a lot of places. If I was somehow an employee and it's like, shoot, your, your, your job has been eliminated. But you were always working out of this whole foods and we're trying to integrate our tech closer into this whole foods and let's just Kroger just because yeah, it's owned by Amazon is a whole different thing. Yeah, okay, sure. Kroger, fine. Wegmans, you know, all of the all of the supermarkets. But there's a place for you there. And you'd be able to do a lot of the stuff that you learned with us because the technology that you're good at and you know, they'd like that could be fine. It's probably pretty often not going to be fine for a lot of the folks that that lost their jobs. And also Instacart just kind of saying like, yeah, that employee thing just didn't work out for us. And there are a lot of other gig economy companies who have been going through this for the last few years. So kind of an interesting precedent if there is one. Yeah. And look, God bless the union organizations in our country. They stick up for workers and they're very good at making sure that the press learns whenever a union worker is fired. That is that is partly what they are there for. That's a lot of the headlines here, despite the fact that it's only 10 people. The larger tidal wave that I think causes this particular issue is the fact that even though we're in a world where home delivery of your groceries has become more of a regular situation than we have ever seen it here in America. The trend has been to go to the grocery store through the grocery store itself as opposed to using third parties like Instacart because the grocery stores themselves are pushing this very, very hard, including Whole Foods which through Amazon and their own process as very good at trying to figure this kind of stuff out. So I think that these are larger business issues that are causing them to reshuffle their business model which means like, hey, take a Instagram trained person and put them on your payroll and that way we can supercharge your ability to Instacart although they might be on Instagram as well. Instacart I apologize. But you can supercharge your grocery delivery operation that much faster if you have one of our people in your midst. Well, I think what's really going on here is Prop 22 has made it safer to use contractors as delivery drivers and Instacart wants to shed off any interpretation that picking the groceries is not part of the delivery that's protected by Prop 22 in California and they want to have closer partnerships with the grocery stores. They've become the official partner for several. So the grocery stores are saying, yeah, we'll employ the people who pick the stuff, prepare the order and you just send the driver that way falls under Prop 22 for you. We have more control over our inventory and who's picking the stuff and don't have random people, you know, clogging up the lanes in our store and works out better for everybody that way. Yeah. All right, let's check out the mail bag. Let's do it. David wrote in about our conversation on Tuesday with Rob Dumblaid about what's up privacy messaging, how it might have been handled differently. David says this is easy. The first time you go to the chat with a company to which this new policy applies, let's call the company Taco Deli, prompt the user that their chat session with Taco Deli will be stored on WhatsApp servers and may be used for future advertisements on Facebook properties. If you want to be extra nice, they could ask for permission once or always and even give away to opt in for all businesses to which this applies. Even if you don't give an option to opt out, this would greatly simplify the messaging similar to the feature on iOS where apps asked to use the camera upon first use. I don't use WhatsApp much says David, but I suspect most users don't chat with companies to which this applies. So those folks won't be bothered until they do. David, I love the solution, except I don't think it's legal. Lawyers who handle terms of service, let me know, but I don't think you can have terms of service only kick in when someone access access as a feature. I think you have to have the terms of service agreed to ahead of time, whether you access the feature or not. And I think that's what WhatsApp ran into is they had to get people to agree. They could have just made it a like, click here to agree and we won't tell you anything until you use the feature, but they decided to be transparent about it up front, but they still would have had to get people to agree to this, even if they never use the feature as I understand it because the way David describes it would be great if you know if that's the way it worked. Well, if anyone has ideas of how to make apps better like David or questions or comments or anything we talk about on any show or future show feedback at daily technewshow.com is where to send those emails. We'd like to shout out patrons at our master and grandmaster levels, including Ali Sanjabi, Paul Thiessen and Kevin today. Thanks to all. Also special thanks to Justin Rubber Young for being with us today. Boy, we're almost through inauguration week, Justin. I know you're you're you're tired, but you got stuff going on. Yes. And and and the the big thing, of course, aside from Joe Biden becoming the 46th president of the United States in the new administration beginning is you can get new merch. Yes, politics merch.com is where you need to go get shirts, hoodies, masks, mugs, laptop cases for three of the shows that I do. Politics, politics, politics, raise the dead 1960 Nixon versus Kennedy or raise the dead 1964 Johnson versus Goldwater. I've got my mask on the way. There's a new mask mandate.  And by the way, folks, folks who think, hey, man, I want to be involved in podcasting. You got a couple of opportunities out here. Daily Tech headlines is looking for someone to help Rich Strafilino. Not an easy job. But if you think you have what it takes to bang out some accurate, well-selected headlines and record them, let us know. Feedback at DailyTechnewshow.com. And you might want to listen to politics, politics, politics tomorrow as well. Because Justin may be looking for a little help, too. Well, for anybody who need just the headlines, though, check out our related show DailyTechheadlines.com. Sorry, go ahead. No, I am sorry, Tom. Please accept my deepest, sincerest apologies. If you'd like to join this show live, because we're live and stuff happens. We're live Monday through Friday at 4 30 p.m. Eastern 21 30 UTC. Find out more at DailyTechnewshow.com slash live. We'll be back tomorrow with Kiki Sanford and Len Peralta. Talk to you then. This show is part of the Frog Pants Network. Get more at FrogPants.com. Club hopes you have enjoyed this program.


And in sports, Cappé was Chelsea's goalkeeper who refused to come off in the league cup final. He could not wait to come to space Liverpool in the same showpiece at Wembley, two years later, but probably wishes he had stayed in the sit. Cappé notoriously blanked manager, Moseiro Sarri, during the 2019 Wembley meeting with Manchester as Chelsea eventually lost on penalties. The outcome was the same this time as Liverpool prevailed, but his role and circumstances were markedly different. Here, rather than the clock, a deaf ear to the instruction of an enraged manager who thought he was carrying an injury, Cappé was sent out to replace the brilliant Mendy. That's a closing moment of extra time in classic goal EFL cup final. Chelsea manager Thomas Tuchel banked on Kepa's reputation as penalty specialty, but was not rewarded as he failed to save any of Liverpool's 11 penalties. He sent the decisive spot kick in the general direction of not secular to give Liverpool the trophy for a record nine time in the first Wembley final success for a decade. He's made that look easy, hasn't he? Come on, Kepa. Oh, Chalever has to make it 20. He does. 10, 10. He's roofed it. 11-10. He's missed. It's not even close. Liverpool. You get notified about fresh news updates.


I'm really excited for this next talk. Uptchive is a nonprofit organization that provides students with free online tutoring and support counseling. Uptchive's unique approach to supporting students resonates in so many ways with GitLab. It's all remote, it's community-driven, and it's focused on creating a world where everyone has the tools they need to contribute. Trey and Dave from Uptchive are here to share how they use GitLab. From epics to feature flags, you'll see how Uptchive is utilizing the power of GitLab's modern DevOps platform to drive great outcomes for their students and volunteers, make their team more effective, and grow their community. Enjoy. Welcome to Using GitLab to Empower Low-Income Youth. I'm Dave Sudia. My co-presenter is Trey Stevens. And we're going to be talking about how our nonprofit Uptchive has adopted GitLab this year to really accelerate our ability to deliver our product that provides tutoring to low-income high-schoolers. Yeah, so first, we're going to dig in a bit. So what Uptchive is and who we are. And as Dave said, Uptchive is a nonprofit. And we offer free 24-7 one-on-one live tutoring for low-income high school students in the US. We currently offer tutoring in various subjects in math and science, like algebra, calculus, physics, biology, et cetera. And we also offer college counseling help as well. Uptchive can be found both on the web in mobile lab and open source. So anybody is free to come out and help. But most importantly at Uptchive, and this is really at the core of who we are, is that we want to close the opportunity gap. We believe that everybody should have an equal opportunity to education. And it shouldn't matter your color, where your background is, or the neighborhood that you're from. Our vision is to democratize access to academic support so that all students have an equal opportunity to finish high school, attend college, and achieve upward mobility. And I think it's really important to highlight that we're not a library. We're building an application here. And we're inviting the community to build that with us. Yeah, and that's one of the reasons that GitLab has been so powerful for us, is that if we're just an open source project, I think we could be more places more easily and just have our issues on our repo. But being really an open source organization where we have lots of repositories, where we act with lots of stakeholders is one of the reasons that we need so many of the features from GitLab. So let's talk a little bit about how UPCHIEVE works. So students can sign up for the platform as long as they go to an eligible school or have an eligible zip code. And from there, they're able to request for a tutoring session right away. Volunteer tutors sign up for our platform and go through an approval and onboarding process. In our approval process, a volunteer tutor will go through a background and a reference check. Wow, and the onboarding process of a volunteer tutor will take the necessary training to learn how to use the platform and how to have sessions with students. They will select hours in a given day in which they're available to actually help students. And they also complete a quiz to get certified in the subject. So once that approval and onboarding process is complete, the volunteer tutor is ready to help students.  We eventually connect the student and volunteer to a virtual classroom. And there they can collaborate on the whiteboard and chat so that the students can receive the help that they need. And now that we talked a bit about UPCHIEVE and how it works, we're gonna talk a little bit about who we are. And I'll hand it over to Dave to introduce himself. Yeah, so yeah, I'm Dave and I'm the CTO. I've been here since the beginning of January of this year. I'm realizing I may now no longer be recognizable from my headshot. But yeah, my journey to UPCHIEVE is I have ADD and I have bipolar disorder. And I did pretty poorly in school and I ended up leaving school early. California has a test you can take to get out after your sophomore year. So my diploma is from the state of California, not from a school. And I kind of bummed around doing random stuff for a while.  So I was a special ed teacher for seven years before I ended up pivoting into tech. And coming here has been a great opportunity to really marry those like the talent and passion I feel like I have for technology, but with my original sort of purpose of helping uplift people who are facing any kind of adversity. And so yeah, that's how I ended up here. Yeah, and my name is Trey Stevens and I'm a software engineer at UPCHIEVE. I joined UPCHIEVE in January, 2020. And before UPCHIEVE, I was just a college dropout working overnight stocking shelves at Home Depot, trying to be a music producer, kind of throwing parties all over the place and just trying to figure things out. And I remember deciding that I wanted to do better for myself. So I picked up some programming books, started to learn how to code. And a couple of years later, I saw a software engineering position posted from UPCHIEVE and I was just super connected to UPCHIEVE for multiple reasons too. One being that we're actually helping kids. I know a lot of people that went down different paths, like nobody cared about them, teachers didn't care, the school didn't care and granted some of them didn't care about school either at that point in life. But sometimes you need a cheerleader to be in your corner to help you do something. And I think UPCHIEVE would have been the cheerleader for a lot of those people. And I also like to just help people learn stuff. I used to help organize a meetup where we taught people how to code. And it was super rewarding to be a mentor and help people grow and move on to get jobs. So that's enough about who we are. We'll talk about some of the challenges that we had as an organization and why we made the pivot to using GitLab. So a big challenge for us is that we had way too many tools. Everything that you see on the list here was in separate places and it started to cause a lot of friction. We had a lot of uncertainty on where to find something, where should we make updates? And if we make updates, where else do these updates need to be reflected? So for example, our product management and issue management were split across two platforms, GitHub and Monday. Sometimes even Slack, but we're just gonna ignore Slack for now. GitHub and Monday, Monday was used by staff members, but GitHub was used for our open source community and we tracked our product progress and direction there as well. Staff would pick up tickets on Monday, spec it out and not have these changes or internal discussions reflected on GitHub. And over time, this started to create a long list of GitHub issues that were either no longer part of product direction, no longer needed to be fixed or completely had different requirements. But these issues would then get picked up by our community members and to cause friction because now we have members working on stuff that is no longer valid. So we needed a better way to marry the product management and issue management. We had two separate CI tools running, CircleCI and GitHub Actions. We also had our documentation existing in multiple places and became hard for somebody to get the answers they needed independently. And finally, we simply did not have enough tools because we didn't have tools like security scanning and feature flags. Yeah, and we had tons of stakeholders and perspectives. We have staff and even within staff, we have the engineering staff, we have our product manager, we have design, we have the programs and marketing people and they all needed to have some kind of insight and ability interact with the system we were using for product management and for development. And we have our open source tech contributors who come in and help us work on the applications. And we had volunteers who were coming in on the programs and business sides and we needed to be able to easily and quickly onboard them and get them places. And we're gonna kind of talk through the, now how we ended up solving a lot of those challenges by moving to GitLab. And the first piece of that is around product management and issues. And I think this is probably the biggest effect and change that we've had because I don't know of another product management tool that is as comprehensive and can be public, right? And so that's a big thing for us because we are a transparent organization. We're an open source organization and a lot of tools in this space, you can make your boards, whatever, but you've got to log in to see anything. And so to have something that can handle ethics at an organization level because we have lots of, we have a front end and a backend and a mobile app and infrastructure as code and any given Epic might have issues across a number of repositories. And we also sort of use the group and repository structure in GitLab pretty flexibly in having like a staff requests repo that pretty much only exists to have issues in it. And that is the place where like our internal staff can go and say, I need a database change or, hey, can you update this page for me? The sort of smaller things. And they don't have to interact with like the full complexity of the rest of GitLab but it's there and they can access it or public stakeholders can access it. And it's really smooth that way. I think the only major complaint I've had in the last seven months was pretty commonly I'd be like, man, the only thing I hate is that I can't put my epics in order unless I like commit to a dates on a roadmap and I don't want to do that. And then 14.0 dropped and now we have Epic boards and I can put them in order and I'm very happy about that. But yeah, so being able to handle things at that organizational level because we're an organization and not just a project has been really impactful. Yeah, and a great thing about GitLab is that we're actually able to work with multiple agile workflows. So our staff uses milestones as sprints but our community contributors do not operate in sprints. They operate in a combine move it across the board style and GitLab allows us to support both without really doing much extra work. Yeah, and that's true internally as well. Our designer has also just, we split her time with the marketing team and she works in a much sort of simpler process than us in terms of getting component designs and designs up and stuff. So for phases on our board than she does and as you can see here, we split into our community development board or design board, our staff development board and what's really brilliant about all this is just how flexible it is and that it's a canonical list of issues. We don't have to have separate boards or separate projects to have boards but it's completely separate projects to have like Kanban and Scrum based sort of views and workflows. It all comes back from the central data set that's just labeled and then we can work off the labels so that every team can view and work with those issues as is appropriate to them. Yeah, and as we talked about earlier, our documentation was in multiple places but now we're able to have documentation that not only sits at the project level but at the org level as well and the new what you see is what you get editor introduced in 14.0 is amazing for the non-tech members of our team to like go in there and actually make edits to the Wiki documents when needed. Yeah, I can work in Markdown but Shelby the philanthropy coordinator does not have to, right? It's really nice. Yeah, another place that we've really been accelerated is in CI and the main thing for me of GitLab CI is the flexibility. So coming on one of the first things I did was in January as I containerized our app we were moving to a new deployment method and I'm looking at the kind of the state of our CI then and going, okay, we've got two different service providers. Oh, that's because we're on the free tier for both of them and we need to really tightly manage those resources and we're using this for that work and this one for that work and we're in GitLab's non-profit open source program so we have the benefits of their top tier for free which is just an incredible thing for GitLab an incredible program for them to have because it has unlocked so much for us to come over and just be able to essentially use the auto DevOps pipeline to just get a CI pipeline going without a whole lot of effort. We did a little bit of customization around like our test job and we's Mongo and not Postgres so we kind of swapped that out in the test job and otherwise it just worked and we were able to run everything on shared runners for a long time. My total tech budget for the year is smaller than most SaaS vendors just cost for a year so anything that allows me to at least even buy time to find funding for things is great. So being able to run on those shared runners we were able to just basically move right over and be more productive than we were but over time we've been able to customize our job so we ended up splitting the test job out in front and back end we ended up customizing the container build step for to fit our purposes a little better but we still use a lot of the auto DevOps pipeline jobs like security scanning and stuff. We also found over time that there were jobs that we had that on the shared runners were taking way too long or they were using more memory than the shared runners offered and I'm not complaining about that because again free but using those shared runners gave us time for me to find budget to stand up a couple of like digital ocean servers to act as runners of our own pretty cheaply and now we can use the tagging system to say all right the container build that can take 10s of minutes on the shared runners but takes six minutes on our runner that one's always gonna run on ours. The back end tests are always gonna run on ours because they're a little memory heavy but the front end tests and the link job those can still run on the shared ones and so we can really maximize our resources in a way that I haven't been able to do on any other platforms before and then similarly like we have a mobile app we have to do iOS builds in CI and I was DevOps engineer for several years and that's very expensive to do most other places and here I was able to pick up a couple of used Mac minis and make my own little iOS build farm because the GitLab runner can just kind of run everywhere that you need it to run which is really fantastic. So there's a couple of the pieces operationally that what we've discussed so far are things that we consolidated on to GitLab but there are things that are features here that we just didn't have before that we would have had to go find a new vendor I would have had to contact them and say what's your nonprofit policy can you offer me any discounts? You know and if not let me go talk to my executive director and find budget and by being here in this sort of centralized DevOps platform they're here and we could just start using them without having to go find them. Yeah and one of them is feature flags. Feature flags have changed the way we think about pushing features to production at upchief. We've gone from creating large branches of feature work to pushing out small batches of feature work to production. So this has helped us reduce the mental load of working around large features and reduce a ton of wait time for dependency. So for instance, we can push completed front end work to production without having the backend fully implemented yet, which is great. Another thing to note is that managing feature flags is equally as important as using them. And we manage feature flags by using labels on tickets with which feature flags we currently have on and which were ready to be removed. This makes it very easy to see the status of your feature flags on a board. And this can be taken much further by creating more specific flags depending on the types of feature flags you're using mainly creating more specific labels around there to identify those type of feature flags. But currently at upchief, we mainly use feature flags to hide incomplete or time sensitive features from users, but we'd love to use it for much more. Yeah, and there's an issue right now where we have a spa, we have a single page app written in view and the Unleash client, which is the feature flag that GitLab uses is insecure around hiding like user IDs and stuff. If you are talking directly through the browser client build or package. So, you know, for a while Unleash, they have a proxy that you can use, but they're kind of hiding it, not hiding it, but it was behind their enterprise offering. And then they open sourced it a while ago and I'm going, okay, I'd love to use this now because I want to be able to add more capability, but it's not part of the GitLab offering at the moment. And so I kind of went, and this is what I love about working with other transparent organizations like GitLab, is I was able to go through the issues for GitLab and actually find that there's a conversation around adding the proxy for Unleash into GitLab's offering so that we can use the browser client with more security. And I, you know, for me as a relatively small fry, being able to, you know, find that, not just be wondering if one day this is gonna happen and, you know, I comment and I can even see the status of that issue, which is right now, it's waiting for demand. And so I was able to post a comment and say, hey, I demand this and show that, you know, it brings me deeper in to the ecosystem here knowing that I can see what the roadmap is and where things are going. Yeah, there are a couple of other things that we've gained, the security scanning capabilities that are built into the AutoDevOps pipeline, is something that, you know, I would have had to go and find a vendor for, instead they're there, they just get dropped into the dashboard. I was actually able to leverage this into finding, you know, someone from the broader tech community who's a security analyst, who, you know, I look at those reports and I'm kind of like, there's a lot of noise here and I don't know what's actually important, but because they exist without me having to have done much more work, I was able to go find someone who was willing to come in and look through our issues and the reports and say, yeah, here are the things you should really care about, here's what you should be working on and leverage the community in that way because everything is public and open and we can share it. Another thing on this topic that I think is really cool is private issues. We are, you know, one of the parts of being in this nonprofit open source program that GitLab has is all your repos have to be public. And that's great, that's why we're here. But if you have security vulnerability, especially for an application like this that's live and running and has, you know, PII in it, I don't just want to put that out on a public board. And so being able to have sort of, I don't remember if private's the right word for it, but like ethics and issues that only, you know, organization members can see was something that I didn't even, you know, think would exist and has really enabled us to engage with the security community much more effectively to try to secure our app. And the last one is just container package registry. Again, lots of vendors for that, but I'd have to go find them. It's built in, CI integrates with it really easily. It just goes right up and, you know, was made our, made our transition to containers and into deploying the containers instead of binaries just so much nicer. Yeah. So last thing is our community. And go ahead, Joy. Finally, our community. GitLab has been an excellent place for our community contributors. We've gone, we've grown from two regular contributors to seven within six months. And since we started using GitLab, it has really become an all in one solution for us and has reduced a ton of friction with our contributors on where to find things, see what the staff is working on and gather requirements from other staff members in our team, if they needed to. GitLab has the Slack integration that also has helped us a bunch. We were able to stay up to date with what our contributors are working on. And for our weekly tech team meetings that we have with the community, we've adopted this agenda model that GitLab uses for the remote meetings. And lastly, we love all contributors, whether you are a beginner or expert, or if you like to just work on documentation or contribute to feature work, we welcome all. So please feel free to go to the link and join us. And thank you for watching.


The Department of the Navy's Sexual Assault Prevention and Response Office is still looking to you to fill out the 2013 Sapper Survey. Rear Admiral Sean Buck, the director of the 21st Century Sailor Office, said he is constantly asked how sailors can make a difference. This survey is one way you can.  SecNAV announced the 2013 Department of the Navy's Sexual Assault Prevention and Response Survey earlier this year. There is still time for you to tell SecNAV how sexual assault in the Navy affects you. Log on to take the survey on your computer, phone or tablet before January 6th. The password for all military participants is 2013Survey. From the Defense Media Activity, I'm Petty Officer Andrew Johnson.


So, I've been working on a programming language called Animus, and in this video I'm going to give you as quickly as I can a justification for why I'm creating this language. So, in short, Animus is a new dialect of Lisp, and it's based very closely, at least semantically, on a dialect of Lisp called Closure. But at the semantic level, Animus makes a few key changes to make the language more comfortable for people familiar, say, with Python and JavaScript. Most notably, Animus makes it easier for you to program in a more familiar imperative style rather than Closure's usual functional style. Aside from this, Animus makes a few changes that allow for tools to give you some of the conveniences you usually only expect in static languages, like, for example, the ability to reliably do name refactoring. And lastly, another goal of Animus is to do something about language pollution, that is, the proliferation of all sorts of different domain-specific languages. This is one of the more speculative goals of the language, and at this point I'm not going to say much about it. So you're probably wondering, why do I call it Animus? Well, first off, it's spelled Animus with a V, but the V is pronounced U, so just pretend it's Latin. This funny spelling was deliberate so that it will come up uniquely in Google searches. As for the choice of the word Animus, this was mainly a play on Scheme, because Animus is a Latin word having many connotations, and those connotations include liveliness, spiritedness, animatedness, but also intelligence, intention, and planning. And aside from all that, apparently there's a megazord named Animus. So again, Animus is based quite closely on closure, in fact the implementation I'm working on pretty much just lays on top of the closure implementation. So the question is, well, what's wrong with closure? Well, closure is a very nice dialect of Lisbon and has many interesting ideas, which are pretty much all retained in Animus. But the usual complaints apply, the usual complaints about Lisbon. First off, there's all too many parentheses, but then specific closure syntax. You then exchange some of those parentheses you usually have in Lisbon. They get exchanged for square brackets and curly braces. And then also like in all Lisbon, you have these apostrophes floating all over the place for quoting. And then in closure, you also have some syntactical oddities with some special reader syntax involving stuff starting with the number sign and the carrot sign and the at symbol. And then you have some weird business about symbol resolution rules. Symbols containing dot and symbols containing slashes get resolved in special ways, which is a bit complex. Part of that has to do with the way interop with Java is done. And then like in any Lisbon, the indentation style is very hard to read. When you look at the left edge of closure code or any Lisbon dialect, the left edge is very jagged and I think very hard for beginners to pick up on the indentation style. And then like in any closure or dynamic language, you have poor syntax highlighting and other sorts of editor assistances. And as I mentioned briefly, that's something that Animus tries to address. And finally, and this is probably the biggest one, at least semantically, and that is closure really does impose immutability on you. While closure has some very interesting and promising ideas in this area, it's still, I think, too much for programmers coming from, say, Python and JavaScript. There are other advantages that Lisb offers, which would be nice if those programmers could take advantage of without having to totally rethink how they structure their programs from top to bottom. So again, Animus is implemented on top of closure and what gets changed is obviously, first of all, there's a different reader syntax. Some names in the standard library get changed. Some functions in macros, their arguments or their names and their functionality changes just a bit. And also we add some new functions and some new macros and also some new types. And in the underlying compiler, we have to change a few of the special forms and tweak the rules for symbol resolution a bit. So what do programmers get when they come from Python and JavaScript? What about Python and JavaScript actually need to be fixed? Well, the first thing that's obvious to me is that Python and JavaScript just simply have too much syntax and they don't have proper macro support. And on top of that, they don't have decent editor instances like say automatic name refactoring. And as it stands today, Python and JavaScript don't have decent support for threading. In fact, Python doesn't have real support for threading at all. And just very broadly speaking, I've always felt using JavaScript that there are aspects which should be more like Python and using Python, I've always felt there should be aspects which should be more like JavaScript. And in both cases, there are aspects where they should be both more like Lisp. So for example, I've generally felt that the JavaScript type system should be more like the Python type system. And in Python, I missed certain allowances like say, the ability to easily create anonymous functions as expressions in a way that's more flexible than what Lambda in Python allows. And then in both cases, both JavaScript and Python, they both should have Lisp like macros and also they should allow for the control flow style found in functional dialects of Lisp like Closure. So to accommodate the style of programming JavaScript and Python programmers are used to, Animas adds to Closure three basic things. There are closer analogs to the usual control flow structures like while and if LF else. These don't supplant however the traditional Lisp control flow structures. They're all there. They're just these are supplements to them just for familiarity's sake. And more significantly, Animas also has a class mechanism modeled after Python's classes. And finally, probably most importantly, the collection types in Animas are by default actually mutable, rather than immutable. So in Closure, when you create class instances or when you use the square brackets or curly braces to create collections, those are all immutable. And Animas, however, that changes and all those types are mutable by default. If you want to create an immutable collection in Animas, you use the same syntax but you proceed it with a hyphen. Now you may notice I keep using Python and JavaScript as the example dynamic languages whose users I wish to accommodate with Animas. So you're probably wondering, well, what about other languages like Perl and Ruby? Well, in truth, I don't really think there's much difference semantically between Perl, Ruby, JavaScript, Python, PHP, basically all of today's popular dynamic languages. There aren't huge differences really. I just think of Python and JavaScript because those are the dynamic languages I far prefer to the others. And that's because I consider them to have much more sensibly designed type systems and also syntaxes. In my mind, Perl, Ruby, and also Bash represent what I think should be considered a dead end in the programming language design. Specifically, these three languages all go about syntax in entirely the wrong way. A good syntax, I would argue, is these four things. First off, it's easy to learn in the first place. And then once you've learned it, it should be easy to type and edit. And then it should be easy to mentally parse so you can scan it and notice errors quickly. And finally, and perhaps most importantly, it should be easy to reason about. And primarily what that means is that the syntax should have few context-sensitive rules. For example, C has a number of icky context-sensitive rules, such as the meaning of asterisk. Sometimes it's a unary operator in an expression. Sometimes it's a binary operator in an expression. And sometimes it's a unary operator in a declaration, not really an expression. And parsing the difference between those three cases is something every C programmer has to learn. For another example, simply the use of parentheses in a C-style syntax language is very context-sensitive. Sometimes it's used just to surround an expression, and sometimes parans denote a function call. Sometimes they denote a macro call. Sometimes they enclose the condition expression of a control flow structure. And sometimes they're just enclosing the params of a function definition. Or for another example, considering Java use of dot. Most often, dot is used to access a field or to invoke a method. But sometimes it's just used to separate the components of a package name. Sometimes it's used to separate a package from the class, which is inside that package, and so forth. So again, the problem with these context-sensitive rules is that perceiving the different context, it's a skill that's very hard to learn in the first place. And even once you learn it, it's something which is just a mental burden that you constantly have to pay when you read code. When syntax is hard to reason about, the reader has to constantly account for special cases. So what's wrong especially with Bash, Perl, and Ruby? Why are they especially bad syntaxes? Well, on the spectrum of all languages, they fall squarely on the extreme of the hetero-iconic side, whereas Lisp is at the other extreme of the homo-iconic side. In hetero-iconic languages, everything has its own special syntax. And so when we then wish to introduce syntactical conveniences, those things end up being their own special cases. It's an ad hoc system of piling one syntactical convenience upon the other. And then what typically results is a syntax that's very hard to reason about because it's full of all sorts of special cases and weird interactions between the different parts of the syntax. When you have a homo-iconic language like Lisp, however, syntactical conveniences don't have to be introduced as special cases. You can have this one general-purpose mechanism called macros that gets you all the syntactical compression you should want. So this argument suggests that homo-iconic syntax is the ideal in syntax design. But the homo-iconic syntax of Lisp quite famously really does have some serious problems. So what does Animas do to address those problems? Well, the first thing always criticized about Lisp is the preponderance of parentheses. So Animas needs to do something to cut down on the number of parentheses. The other major problem with Lisp syntax, though one not cited nearly as often as the preponderance of parentheses, is the strange indentation style. The key to reading current Lisp syntax with any fluidity at all is to get accustomed to the strange indentation style. But rather than requiring people to adjust to that indentation style, I think it should just be reformed. So it's more sensible in the first place. Another problem I find with Lisp syntax, though this is something not often pointed out, is that the whole system of quoting is first off really quite confusing and secondly is just ugly because it seems to require apostrophes scattered around at seemingly random places in your code. The solution for this problem in Animas is to simply redesign the special forms and the standard macros so that they avoid quoting as much as possible. Finally, the last major problem with Lisp syntax, and this is again something which is not often articulated, but a major thing which makes it hostile to non-Lispers is that Lisp syntax does not have a look. And what I mean by this is that in most languages, programmers become accustomed to look for certain patterns of special symbols and certain patterns in the reserved word highlighting to help them see the outline of their code. In Lisp, you usually don't have this same style of highlighting and the code all looks too uniform to give it any shape. This is the major downside of Homo-Econic syntax. When everything is uniform, everything looks the same so nothing stands out. So the way Animas compensates for this is that it has a unique and much more elaborate system of highlighting than what you're used to in most languages. And as you'll see, this highlighting scheme gives a shape to the code and makes things which need to stand out stand out. So first off, how do we cut back on the number of parentheses? Well, the first thing that has to go is this convention in most Lisp's which is called grouping. Here, for example, is a let form in scheme where the variables being assigned to, having values bound to them, encloses all of those pairs of variables and values in a set of parentheses and then each pair is in self in another pair of parentheses. These parentheses do not, like most other parentheses in Lisp, denote the invocation of a function or macro. Rather, they are just used in this form, this special form let, to group these arguments to pair them up. The x3 in parentheses here is not a function called to some function called x with an argument 3 is just matching the symbol x together with the value 3. So to make this clear, here in orange are parentheses which are being used expressly for grouping purposes. Closure itself actually takes a very sensible step to cut down on this preponderance of grouping parentheses. First of all, in these binding forms, like with let, it uses instead just a single pair of square brackets to enclose all of the pairs rather than enclosing each one in its own pair of parentheses and then enclosing them all in another pair of parentheses. So that right there closures off to good start, but animus actually goes the very last step and simply gets rid of any delimiters whatsoever. The convention in animus is that binding forms like let simply list their symbols with accompanying values and then the body is where the first form that is enclosed in parentheses. So we don't actually need any parentheses or any other delimiter to set them off. The let form can simply infer from the types of the arguments. Now you might object here that looking at this, you can't quickly see which variables are being declared, that everything here just kind of runs together. The answer to that as you'll see is that highlighting fixes that problem. Now grouping is used not just in binding forms, it's used in some other contexts, some other special forms and macros, and the convention there in animus is to simply use a specially designated symbol to delineate the two groups. So here, for example, imagine some macro foo and rather than grouping its arguments into two groups with parentheses, we just delineate them with a specially designated symbol, in this case, bar. So getting rid of the parentheses of grouping goes a long way to cutting down significantly on the number of parentheses, but to go much further, we have rules in animus about implicit parentheses and indentation. First off, to keep everything nice and regular, animus has a strict rule that every line must begin with the number of spaces, which is a multiple of four. So either zero spaces, four spaces, eight spaces, 12 spaces, or so forth. And tab characters are simply not allowed, that's always a parsing error. The other part of this rule is that when we indent something underneath another line, we always indent by just four spaces, never anything else. So you never have situations where you use double indentation to indicate that these lines are actually continuation of something on the interior of the preceding line rather than continuation of what's at the start of the preceding line. Quite deliberately, there's no allowance for that situation. You're always indenting by four spaces. The second rule is that when you have an open delimiter at the start of the line, which is not then closed before the end of the line, then that open delimiter is closed either at the end of that line, or if there are additional lines indented underneath that line, then the delimiter is implicitly closed at the end of what's indented underneath. So consider these three examples. If we have a line reading foo abc starting with two open parins that are not closed by the end of that line, then those open delimiters are implicitly closed at the end of the line. In the second example, we have the same thing, except the open delimiters are first a square bracket than an open parin. And so when they get implicitly closed, they get, of course, closed in the opposite order so that they match up properly. The last example also begins with two open delimiters, except notice that this open parin is explicitly closed with a matching end parin on the same line. That's why the parin is not highlighted. The convention in Animas is to highlight these open delimiters at the start of the line, which are not explicitly closed. In any case, only the curly brace here is left open, and it is implicitly closed not at the end of the line, but because this line has stuff indented underneath, it gets implicitly closed at the end of all that stuff, so it's going to be placed immediately after the four here. Now, for the sake of stylistic uniformity, where these implicit end delimiters are allowed, they're not just optional, they're actually required, so you can't make them explicit. This top example here actually is not legal, it's a parsing error, because you're actually required to leave that end delimiter implicit. Now, the last special rule of indentation and delimiters is that when a line begins with a symbol, that is, a symbol and not some open delimiter or some number, just actually a symbol, then that line implicitly begins with a single open parin, unless that symbol is preceded with a comma. This implicit open parin is then implicitly closed according to our second rule. It gets closed at the end of that line, or any lines indented underneath. So, if you wish to write a line of foo abc enclosed in parins, you don't write foo abc enclosed in parins, nor do you even put simply the open parin at the start, you actually write it with no parins at all. And because this line begins with a symbol, foo is a symbol, then there is an implicit open parin at front, which then is implicitly closed at the end. And then for cases where you wish to write foo abc with no parins at all, you have to write that line starting with a comma to suppress the usual implicit parin. So, if we take an example excerpt of closure code and we apply all of these indentation rules and also apply our changes with grouping, what we end up with is something looking like this, which notice as many fewer parentheses and also fewer other delimiters. Note that this isn't actually proper animus code yet. We're going to make a few more changes as I'll show you. In any case, that example does demonstrate how animus solves the problem of too many parentheses. Now, what about these editor conveniences I was talking about? Well, first consider a typical situation in a dynamic language where you write something like foo.bar with the arguments x and y. If this is code from a dynamic language like Python or JavaScript, then there are many different things that could be going wrong. For example, foo, x and y, those might be variables that don't resolve anything into the current scope and the arguments might not be in the right type or the right order or right number. Bar might not be a method of foo or might not be a member of foo's type at all. And of course, it's always possible that the programmer is making a mistake and simply invoking the wrong method. Maybe bar is not what they mean to invoke here for their purposes. Or of course, it's even possible that even if the programmer gets the types of the arguments right and their order correct and everything, the values themselves may simply be wrong. Because the programmer has made some sort of logic error. The problem in a dynamic language is that these kinds of errors are never caught until the program is actually run. And of course, in some of these cases, the language won't catch the problem at all. You'll just have some kind of weird bug. In a static language in contrast, like, say, Java, most of these problems are fixed or at least fixed in the sense that when the programmer does make these errors, the errors are caught by the compiler. So you don't actually have to run the program to catch most of these errors. Sure, it's possible with dynamic languages to do some very sophisticated kinds of code analysis, type inference and so forth that will, in many cases, catch these errors. But such tools never work 100% reliably and they're not very commonly available and will simply, they just don't work as well. You simply can't get the same kind of consistent assurances in dynamic languages that you can get in a static language like, say, Java. What Animus tries to do that's unique for a dynamic language is it tries to fix at least this first problem, the case where you've made a mistake because you've typed a name that doesn't actually resolve to anything in the current scope. Now, closure actually, by itself, goes a long way towards pretty much solving this problem. In closure, unlike most other dynamic languages, when you use a name, that name, when it then occurs in a function scope, will not be able to solve in a function scope, say, it has to actually resolve to something in the local scope there or it has to resolve to something already defined in the global scope or the module scope, we can call it, the namespace scope. So unlike, say, in Python or JavaScript, when a name is used in a function definition that at that point, at that time of definition doesn't actually resolve anything, that's actually an error. It doesn't work like in Python where the name is only resolved The difference this makes in practice is if I have Python code where a name inside a function is bad, that is, it doesn't actually resolve anything in the module scope, then that program is going to throw an exception when I actually invoke that function and that name is an access of that name is attempted. In closure, however, that bad name is going to trigger an exception when the function itself is defined, not when the function is actually invoked. So in practice, you'll pretty much get that error anytime you start the program. That's very good as far as it goes, but the thing still lacking is that with closure, you can't simply just run your program to discover these errors without actually running your program. The solution to this in Animas is to introduce a second mode of execution or rather what I call a processing phase of the code. Animas introduces a form called run module in which you put a body of code that is only executed when you are truly running the program, so when you write a typical module, you include a bunch of definitions like for functions and so forth, and then probably at the bottom, you include a run module section that's only executed when you are actually running the program. However, though the run module bodies aren't executed, they are compiled. So the processing phase does check at least the basic correctness of the code in your run module blocks. So by compiling the code and executing much of it and actually executing the program, this processing phase, it checks for basic errors, like, say, making sure when you use a name that it exists in that namespace. But a couple other things also happen in this processing phase. For one thing, all of the parsed and compiled code gets preserved in another file, so the norm in Animas is actually like in Python where your code gets preserved as compiled Python object files. So this is a little bit of a closure because closure does allow ahead-of-time compilation, but it's sort of something you have to do manually. It's not just expected by default. The other big thing processing gets us is metadata information about the code. Information that can then be used by text editors to provide a good number of conveniences. The way this works is that the parser and then the special forms in compilation and the macros when they're processed, are in the same mode. This metadata information can then be used in your text editing environment to provide information like, say, clicking on a name and seeing where that name is defined and what it's defined as. This metadata information is what allows your text editor to provide not just syntax highlighting, but different highlights for different symbols depending upon the function of those symbols. The scheme I've devised for highlighting symbols looks like this. The idea is that depending on where a name is defined and what the nature of a name is, whether it's a standard name, a part of the standard library, or if it's something you've defined in that current namespace, or it's defined as a local, or whether it's defined from some other namespace, all those different symbols are going to have different highlights. First, what I call the common names, the things that are all part of the standard library, those are highlighted in blue with the distinction that forms which start a block. Those are both bold and in a slightly different shade of blue. When you define a name in the current namespace, like say when you define a function with a defunct, that's an orange in bold, and then in a module when you use a name that's defined in that very same module, that's also an orange, but a lighter shade and not in bold. When you define a local, that's in dark red, and then when you actually just use one, it's a light red, kind of a pink color. And then in some cases you have macros which introduce local names, but the name doesn't appear defined anywhere, it's just implicitly defined. In that case, it's also the same light red color, but it's bold. And then when we use a name from some other namespace, those are the names in white. And then what I call an exterior namespace is a namespace that's outside the realm of Animus itself, like say when you import packages from Java. Those are names that aren't part of Animus, so those are in that. Brownish, all of green color. And lastly, in bright yellow, a symbol with macro defined meaning is a symbol which in the context of a macro has a special meaning. It's not designating a variable. These are generally used in macros as delineators like we discussed when we talked about grouping. They usually designate a meaning for the argument which comes after them or the body which comes after them. So looking at this whole highlighting scheme in practice, here's the previous example we showed. So again, common names in blue, local names in red and module names in orange. So we're defining a module name factorial here. And I think you can very easily see which names are being defined as locals and is the parameter of the factorial function. C and T and ACC are both locals being defined and then you can see where they're being used. This is something I think which is actually really important because when you're browsing through code particularly code you're seeing for the very first time I believe it's much much easier to get a grasp on the code on just visual glance if you can quickly sort out which names belong to what namespaces. You can instantly see here which stuff is common that is stuff if you know the language you're supposed to already know and shouldn't have any trouble understanding. And then because you can see the difference between the actual and names which are part of other modules what I believe that allows you to do is first focus on the locals because these are things which you can generally understand just in the local context and then you can work outwards. You can first focus on the names and the local module before moving on to the stuff which is defined in totally different files of code. And also keep in mind all this made information that was collected one thing it allows you to do is just hover your mouse over a name and very quickly get a definition of the function from another module does. The last feature of Animus I'll discuss in any detail is what's called the language directive. A directive line must begin with an at symbol and this particular directive must always be the first line in each module. What the language directive does is simply identify which version precisely of the language is being used in this module. So here for example currently the standard directive is preliminary slash 1.0 because currently we're in a preliminary version of the language mark 1.0. The purpose of this directive the reason it's required is to allow easy transitions to future changes of the language. By explicitly declaring the precise version of the language the implementation doesn't have to guess and that at least gives implementations a fighting chance to accommodate modules written for different versions of the language. Of course going forward it's possible there might be more than just syntactical changes in a few tweaks to the standard library there might be some semantic changes in the language and in that case depending upon what that change is it may not be possible to accommodate different versions of a language or in particular to get them to interoperate. But for changes to more superficial aspects like say changes of standard library names having the language directive makes those sorts of changes pretty much pain free. I intend at some point when the implementation is stabilized a bit to make sure the code is flexible enough to allow others to easily insert their own custom dialects to the language. They designate their own language directive string. And this should allow others to both experiment and also perhaps create their own custom parsers like say for some foreign language because currently the parser I'm writing strictly restricts symbols using the English alphabet but others of course may want to create their own variant which supports non-English characters. Of course at some point I might introduce support for non-English characters in the standard variant of Animus but for now I'm just keeping things simple still I think there's value in allowing people to give their own treatment to the syntax because maybe the way the syntax rules work makes sense for English but they don't make sense to say for Japanese. So again I think it's important to allow people to at least try their hand at doing their own thing. So briefly looking at the things we didn't discuss I didn't go into any detail about how classes are implemented though I did hint that there's a class mechanism that takes after Python's support for classes. The syntax for string literals is a bit unique. It's intended to easily allow for multi-line strings. The way Java interrupt is done in Animus is a bit different from how it's done in Closure. In Closure there's some special syntax for making that work whereas in Animus it relies entirely upon just regular macros. All those special syntax rules are removed. The way we write macros in Animus is also a bit different because of how symbol resolution issues are dealt with. Animus also has a second kind of macros called prefix macros which is intended for cases where you want the invocation syntax to be as compact as possible. When it comes to invoking functions my hope is to somehow imitate in Animus the style of function invocation you find in Python where you can have parameters with default values. You have a special mechanism for expanding lists and dictionaries of arguments and you also have a facility for named arguments. I'm trying to work out some way to get to the basics of Animus. And finally when you import a module in Animus the way modules are located the way we resolved a module by its name is quite unique. I won't get into it here but it differs quite a bit from what you usually expect like say in Python. And along with this unique system of module resolution there's a concept of what are called manifest files and resource directories which again I won't get into here. Well, I hope that gives you an idea of what Animus is about. If you want to learn more go to animus.com and just remember Animus is spilt with a V instead of a U.


So, we've already had a look at what gallstones are. We looked at the types of gallstones, what the risk factors are and what you can do to prevent getting gallstones. We also mentioned how common gallstones are and that most people will have gallstones without even knowing about it. They are asymptomatic. We use the term gallbladder disease in all patients who develop symptoms because of their gallstones. The most common problem caused by gallstones is uncomplicated gallstone disease otherwise known as biliricolic or a gallbladder attack. So you've just had an attack of severe right-sided upper abdominal pain and together with that you might have experienced some nausea or even vomiting. Usually that follows a large meal, specifically dinner and if there's a lot of fat in the dinner and that means it usually occurs at night. For most people this pain will only last for about half an hour up to several hours but then disappears. If the pain disappears before you seek medical help there's about an 85% chance that you might develop further attacks. When you do get to hospital you'll get an ultrasound to confirm the presence of gallstones. If your symptoms were very specific for biliricolic and they didn't find stones we might ask you to come back in about two weeks time so we can just do another ultrasound to look for missed stones. During the ultrasound they'll also check for other complications of gallstone disease. You might also have your blood drawn to look for diseases of the liver, complications where the stone lands up in the bile ducts or even blocks the pancreatic duct leading to pancreatitis. It is good practice to give patients with biliricolic some good analgesia. If you had severe nausea and vomiting you might also get intravenous fluids just to replace that water and the lost electrolytes. So why did all of this happen? Let's have a look at this image of the gallbladder full of stones. One of the stones are migrated to the opening of the cystic duct. Now the cystic duct connects the gallbladder with the biliri tree and that is where the bile runs back and forth. After a meal, especially a fatty meal, chemicals will be released from the duodenum that is your small bowel when food reaches it from your stomach. This chemical goes through your bloodstream and acts on the smooth muscle cells in the wall of the gallbladder causing contraction. The stone will then block the flow of bile and that causes severe pain as the gallbladder spasms up. The attack is relieved as that stone drops back into the gallbladder. As I mentioned your chances of getting another attack are quite high. So in most cases we will recommend that you undergo removal of your gallbladder. That is a colisostectomy usually done laparoscopically. Since this is not an absolute emergency we might book this on the next elective list. This will of course happen only if you are fit for surgery. If not, we might embark on expectant therapy and in most cases that will only involve simple analgesia. That is where you will be given analgesics just to take care of those acute attacks of pain. The reason why most surgeons will suggest a colisostectomy is that the risk factors for complicated gallstone disease are higher than the complications due to the surgery. If you are going to have surgery of course always discuss the benefits and the risks of that surgery. There are alternatives to the removal of the gallbladder. The most common alternative for my therapy is dissolution of the gallstones. Now there are products on the market that can dissolve certain stones. Unfortunately dissolution therapy fails in most cases. That is not something that we use routinely. Lithotripsy that is where external shockwaves are used to crack up those gallstones unfortunately have no place in the management of gallstones. Biliricolic is a severe attack of pain. Fortunately, most people with gallstones will never have symptoms at all. If you do suffer about a biliricolic and the pain persists, really do seek some medical advice. Pain that persists is really the first symptom of colisostitis and that is complicated gallstone disease. I hope you found this video informative. Please subscribe and hit that notification bell so that when I do release new videos you will be the first one to know about it.


What's going on everyone and welcome back to another video. In today's video we're gonna talk about, what's that? Oh, it's my new BG merch hat. Thank you very much Slypod E, but you can go now. As I mentioned before, in today's video we're gonna talk about a unique slider called the Slypod E. There are a lot of motorized sliders on the market but I've never seen a unique slider like this before. I believe you should take a look at the Slypod E because there are definitely some advantages over the standard motorized sliders. The Slypod E was sent to me by Moza. However, I wasn't asked or paid to say anything specific so everything you will hear is my honest opinion. By the end of this video you will not only know how to use the Slypod E but also know if the Slypod E is the right tool for you to use in your videos. Like in all my videos I will be dividing this video into sections. There is a timestamp in the video description below if you wanna skip or go back to a particular part of the video. So here's a quick overview of the Slypod E. Starting from the top you have a quick release adapter which can easily be taken off by turning the quick release screw on the side. Close by you have an ARC Swiss quick release with a one quarter and three eight extension hole. This allows you to mount the Slypod E on a tripod. At the very bottom you have a light indicator. You have a power button and an operating button indicated as plus and minus. You have a Type C charging port and the cable is included as well. What you also get is a nice tripod which can be useful for support and extension. So as for the built and design quality it's made out of aluminium and holding the Slypod E in my hands you can really feel that it's built well. I really like the rubber grip and the simple design. It comes with a back end unlike other sliders the Slypod E is really compact, lightweight, around 920 grams and doesn't take up much space. It has a built in lithium battery which also allows you to charge it on the go. The charging time takes around 90 minutes and the battery life of the Slypod E lasts for two hours. As for the payload when setting up the Slypod E vertically it can carry up to nine kilos and horizontally four kilos which is actually quite a lot. The tube extends exactly 28 centimeters. You know what also extends? My extension cable. Sorry for my jokes. You can connect your smartphone with the Slypod E over Bluetooth by downloading the Moza Master app. The app allows you to have more control over the Slypod E but we will look into that later. Let's move on to setup. To set up the Slypod E I prefer using a tripod. It's much more convenient and I can set up the camera the way I like it to get creative shots. I highly recommend you get a strong ball head that has a plate so that you can adjust the angle of the camera to your liking but also take off your camera to reposition it to get a different moving shot. By the way, all the additional gear mentioned will be in the video description below. To mount the quick release adapter I can slide it in, tighten the knob and turn the quick release screw to secure the adapter. It's safe to say that I can leave my camera on the Slypod E without worrying that it will fall off. If you want to use the tripod legs that is included you can use it to set it up vertically or get really low shots. Next is the functionality. One of the best things about the Slypod E is that it's really simple to use. Once you have everything set up you can hold and press the power button until a solid green light appears. Press the plus or minus button to extend or retract the slider. By pressing the button once it will accelerate very slowly which is barely visible. This is great for shooting longer time lapses. You can change the speed by pressing the operating buttons more than once. If you want the full speed you can just press hold the operating button. If I want to stop the acceleration I can press the power button twice. If you want to get into loop mode just press the plus and minus button at the same time for three seconds and it will start moving back and forth continuously. This is great if you're filming yourself without the help of another person. If I'm done using the Slypod E I can simply press the power button three times to reset and turn off. By the way all the behind the scenes was shot by George so I wanted to mention him because he's a huge help for this channel so thank you bro. Another benefit of having a slider like this is that I don't have the tracks visible in the shot. So you could really use a wide angle lens and have everything in the frame. Also with a standard slider it's really difficult to get a vertical shot. With the Slypod E you can simply use the tripod leg to create that shot. The simplicity of this slider is really what stands out. Now let's take a look at the Moza Master app. I don't want to go too deep into it since the modes can get pretty advanced. First of all I like the idea that you can control the Slypod E with your smartphone. This is especially great for getting smooth looking shots where you don't want to get in contact with the Slypod E that could potentially create shakiness in your footage. Also if you're filming yourself and want more control you can decide when and how far the slider should move. So once you've downloaded the Moza Master app open it up and select Slypod and connect it to your device. As you can see you have your battery levels displayed on the top below your given different options. In the remote control section you will find different modes. Now most of the time I'll be using the regular mode. In this mode you can slide the red point from the starting point to any position and the Slypod E will move accordingly. You can adjust the speed as well and use the upwards or downwards key to set the slider in motion. You can actually also take a still or start recording a video on your camera if you have the additional cable. In the creative mode you really have a lot of advanced options where you can create different path and work on different parts of the slider which gives you a lot of flexibility. One of the downside of this slider is that it's noisy. You probably wouldn't want to use this at full speed on an interview shoot but what you can do is enable silent mode which will reduce the accelerating speed of the slider making it less noisy. In the settings you also have the option to change the color of the light which is pretty awesome. All right let's move on to the usability. So how smooth is the footage using the Slypod E and how can you use it creatively in your videos? So here are some test footages I shot outside using the Slypod E at maximum speed. So as you can see it does a really great job of keeping the shot steady. I find that the Slypod E is really great for shooting b-rolls or filming yourself and especially also for product videos since you can really angle your camera however you like it to get those dynamic shots. Whether you're using a DSLR camera or a smartphone both work really well. For vertical shots I don't recommend using a heavy camera since it can unbalance the tripod. If you do make sure to use counterweights. All right so here are my pros and cons using the Slypod E. Starting with the cons, the slider is loud at full speed. For that reason I personally like using it for shooting b-rolls. The length of the slider can be restrictive depending on your shooting needs. For shooting product videos I find the length of the tube more than enough and also for these revealing shots works really great. Either way if you want to be more flexible I highly recommend you get a good tripod that allows you to position the Slypod E freely to take away some of the limitations. For example if you want to create a vertical shot you can extend the legs of the tripod to your desired height to create an interesting move. Now moving on to the pros for the price of 300 bucks you really get a unique slider. There are a lot of motorized sliders out there that are way more pricier. With the Slypod E you don't have the tracks in the frame and like any professional video equipment they all have their own purpose. The Slypod E is great for run and gun shoot since I'm very impressed on how quickly and easy it is to get it up and running. You get smooth looking footage and having that buttery smooth movement in your shot just makes the video more engaging. I especially enjoy the Slypod E for filming myself or shooting B-roll or for product videos. It's just much more efficient. With a normal slider it took me much longer to set up the shot. So hopefully this video helped you decide whether or not the Slypod E is a tool for you to use. If you have any questions feel free to write them in the comment section below. Thank you so much for watching. It's a real pleasure to have you on my channel. If you're new make sure to hit that subscribe button. This will allow me to create more awesome videos for this channel. If you're interested in some of the gear I use make sure to watch these two videos right here to learn more. Until then have a great day, take care and I will see you in the next video guys.