Podcasts about Assembler

This episode features Geoffrey Decker, an instructor in Computer Science at the Northern Illinois University (NIU) and a firm believer in quality over quantity when teaching programming. Geoffrey encourages getting students “down and dirty into the programming” — not just teaching theory or showing pictures — so they truly “program and really test their skills.” His goal? Geoffrey wants students to learn so well that “they can teach themselves advanced techniques.” Advice to educators: His message is clear: “No teacher of programming should just be a droner. Don't drone — bring your enthusiasm and a solid, positive attitude to teaching.” This mindset transformed his tough Assembler class into an engaging experience that sparked students' interest to sign up for and continue with advanced Mainframe courses. Don't miss the rapid-fire questions at the end — you won't believe how many vinyl LPs and CDs he owns! If you guess right, let me know!! 

RJJ Software's Software Development Service This episode of The Modern .NET Show is supported, in part, by RJJ Software's Podcasting Services, whether your company is looking to elevate its UK operations or reshape its US strategy, we can provide tailored solutions that exceed expectations. Show Notes "When you program for the NES you deeply need to understand the hardware, right. And that's not a thing; like as a .NET developer you don't really know what a register is, or like or a bus, or like NES has a thing called a PPU"— Jonathan Peppers Welcome friends to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. We are the go-to podcast for .NET developers worldwide, and I am your host: Jamie "GaProgMan" Taylor. In this episode, Jonathan Peppers joins us to talk about something which is a little out of the ordinary for us here: programming the Nintendo Entertainment System but in C#. We talk about the process behind his (some would say absurd) idea for an AOT transpiler which can convert a subset of C# over to the Assembler required to write and publish a NES game. "So you think about that example, what I described there on the NES side is actually very similar to what's on the IL side, is that in IL, you have a string, right? It goes and looks up in a string table, the contents of the string, and puts it on a stack, and then it calls vram_write, and then it's the runtimes job to actually like make that happen at runtime; or in the case of an AOT compiler it would emit, you know, native machine code that does the same thing."— Jonathan Peppers Along the way, we talk about that Ahead-of-Time compilation is, have a brief intro to what IL is (that's what your C# code is compiled to before running it), and how all of that fits in with .NES—the wonderful name for Jon's AOT NES compiler. Anyway, without further ado, let's sit back, open up a terminal, type in `dotnet new podcast` and we'll dive into the core of Modern .NET. Supporting the Show If you find this episode useful in any way, please consider supporting the show by either leaving a review (check our review page for ways to do that), sharing the episode with a friend or colleague, buying the host a coffee, or considering becoming a Patron of the show. Full Show Notes The full show notes, including links to some of the things we discussed and a full transcription of this episode, can be found at: https://dotnetcore.show/season-7/jonathan-peppers-unleashes-code-chaos-how-dotnet-meets-the-nes/ Links: Native AOT Development System.Reflection.Metadata 8bitworkshop.com neslib BinaryWriter Retron5 Flight68k .NES on GitHub .NES Discord Server Supporting the show: Leave a rating or review Buy the show a coffee Become a patron Getting in Touch: Via the contact page Joining the Discord Remember to rate and review the show on Apple Podcasts, Podchaser, or wherever you find your podcasts, this will help the show's audience grow. Or you can just share the show with a friend. And don't forget to reach out via our Contact page. We're very interested in your opinion of the show, so please get in touch. You can support the show by making a monthly donation on the show's Patreon page at: https://www.patreon.com/TheDotNetCorePodcast. Music created by Mono Memory Music, licensed to RJJ Software for use in The Modern .NET Show

Deuteronomy 20 speaks of laws covering the behaviour of the Israelites in warfare. The priests were to stimulate the courage of the Israelites as they were about to enter into battle. If any man had married recently he would be allowed a year off before joining the army. Similarly anyone would be allowed to partake of their first fruits before enlisting for active army service. Yahweh would fight for His host; however if anyone in the nation was fearful, or doubted their Omnipotent Sovereign's ability to deliver His people then that person was to be sent home so as to not damage the morale of his comrades. For nations other than the seven Canaanitish nations terms of peace were to be offered and if accepted that nation would become a tributary nation. Should terms of peace be rejected then siege would be made, the males of that city would be destroyed and the spoil taken by the Israelites. As for the Canaanitish nations no quarter was to be shown to them, but they were to be totally destroyed. Israel was commanded that during the siege timber could be taken from any tree except fruit trees. Ecclesiastes 12 verses 1-8 instruct us to remember our Creator is the days of our youth. For, says the wise man, the time will come when every desire fails – this he terms the evil day. Those of us who are aging rapidly feel that day encroaching too rapidly. Verses 2 describe the aging process and the declining of the body in a series of graphic and frightening metaphors. Verse 2 speaks of the inability to distinguish light from night and as the bodily heat becomes lost to know what season the aging person is in. Verse 3 tells of the enfeebling of the arms and legs. The same verse tells of the decaying of the teeth and their falling out; and of failing eyesight. Verse 4 is describing the loss of interest in anything external to themselves and the failure to experience stimulation through music and other past delights. Verse 5 describes the anxiety that accompanies aging – everything is an insurmountable trouble. The aged person is resembling a crippled grasshopper dragging itself by its front legs. There is no longer pleasure in anything and the decrepit individual cannot wait for death to come. Verse 6 speaks of the instability of the spine; of the failure of the brain to function; and of the breakdown of the heart. Verse 7 speaks of the end – the body returns to the dust from which it came (Genesis 2:7; 3:17-19). And so, says Solomon, life as an end in itself is entirely meaningless. Verses 9-12 describe the Preacher's exertions to reach wise ways in which there will profit and as assurance of a future. Wise counsel will result in responding to the Almighty and walking in His ways. He will goad us and guide us in the paths of righteousness. God is the Great Shepherd whose Word is firm and His counsel unfailing. And so concludes the Assembler of wise sayings – Koheleth, or the Preacher – in verses 13-14 that the whole, complete, man is the one who reverences God and walks in the way of His commandments. Acts 11 commences with Peter being caused to justify why he baptised Gentiles. We next have a description of the progress of the truth in Antioch in the province of Syria, where believers were first derisively called ‘Christians'. One of these faithful believers is a prophet named Agabus. He prophesies of a great famine that would affect the entire Roman world. The disciples of Antioch start a fund to help Judean believers, who were greatly affected and in dire need. In Acts 12 Herod Antipas kills the Apostle James – the year was AD 44. Seeing how much this delighted the Jews Herod has Peter arrested for execution after Passover. Despite being securely chained between guards the angel of the Lord causes a deep sleep to overcome the guards and releases Peter. Peter proceeds to the house where the ecclesia is gathered to pray for his deliverance. A maid named Rhoda answers the door and runs to tell the disciples that Peter was outside. Rhoda is told that she must be mistaken. The disciples say that it must be Peter's “messenger” (Greek angelos- angel). Peter is admitted to the house and he recounts how he had been delivered. James, the half brother of Jesus. was informed and told Peter to secretly depart to a different location where he cannot be found. Herod kills the guards (verses 20-23). The chapter concludes with an account of Herod's narcissistic claims and his being smitten with dysentery by the angel of God and Herod dying verses 20-23. Nonetheless the Word of God exceedingly prevails.

Been anticipating this Guest mix with Heavy hitter False persona who is one of my favourite musicians atm, after recently releasing a new single with Mall Grab "Crazy" of Fragrance Recordings and playing at the Leeds Warehouse all earlier in February, and he doesn't disappoint with a hard mix in the second hour! ⚡️Like the Show? Click the [Repost] ↻ button so more people can hear it!

Kacper "prefetcher" Staroń created the PinkSea oekaki BBS on top of the AT Protocol. He also made the online multiplayer game MicroWorks with Noam "noam 2000" Rubin. He's currently studying Computer Science at the Lublin University of Technology. We discuss the appeal of oekaki BBSs, why and how PinkSea was created, web design of the early 2000s, flash animations, and building an application on top of the AT Protocol. Prefetcher Bluesky Github Personal site Microworks (Free multiplayer game) PinkSea and Harbor PinkSea PinkSea Bluesky Account PinkSea repository Harbor image proxy repository Harbor post from bnewbold.net imgproxy (Image proxy used by Bluesky) Early web design Web Design Museum Pixel Art in Web Design Kaliber10000 Eboy Assembler 2advanced epuls.pl (Polish social networking site) Wipeout 3 aesthetic Restorativland (Geocities archive) Flash sites and animations My Flash Archive (Run by prefetcher) dagobah Z0r Juicy Panic - Otarie IOSYS - Marisa Stole the Precious Thing Geocities style web hosts Neocities Nekoweb AT Protocol / Bluesky PDS Relay AppViews PLC directory Decentralized Identifier lexicon Jetstream XRPC ATProto scraping (List of custom PDS and did:web) Tools to view PDS data PDSls atp.tools ATProto browser Posters mentioned vertigris (Artist that promoted PinkSea) Mary (AT Protocol enthusiast) Brian Newbold (Bluesky employee) Oekaki drawing applets Tegaki chickenpaint Group drawing canvas Drawpile Aggie Other links Bringing Geocities back with Kyle Drake (Interview with creator of Neocities) firesky.tv (View all bluesky posts) ATFile (Use PDS as a file store) PinkSky (Instagram clone) front page (Hacker news clone) Smoke Signal (Meetup clone) -- Transcript You can help correct transcripts on GitHub. Intro [00:00:00] Jeremy: Today I am talking to Kacper Staroń.  He created an oekaki BBS called PinkSea built on top of the AT protocol, and he's currently studying computer science at the Lublin University of Technology. We are gonna discuss the appeal of oekaki BBS, the web design of the early 2000s, flash animations, and building an application on top of the AT protocol. Kacper, thanks for talking with me today. [00:00:16] Prefetcher: Hello. Thank you for having me on. I'm Kacper Staroń also probably you know me as Prefetcher online. And as Jeremy's mentioned, PinkSea is an oekaki drawing bulletin board. You log in with your Bluesky account and you can draw and post images. It's styled like a mid to late 2000s website to keep it in the spirit. What's an oekaki BBS? [00:00:43] Jeremy: For someone who isn't familiar with oekaki BBSs what is different about them as opposed to say, a photo sharing website? [00:00:53] Prefetcher: The difference is that a photo sharing website you have the image already premade be it a photo or a drawing made in a separate application. And you basically log in and you upload that image. For example on Instagram or pixiv for artists even Flickr. But in the case of an oekaki BBS the thing that sets it apart is that oekaki BBSes already have the drawing tools built in. You cannot upload an already pre-made image with there being some caveats. Some different oekaki boards allow you to upload your already pre-made work. But Pinksea restricts you to a tool called Tegaki. Tegaki being a drawing applet that was built for one of the other BBSes and all of the drawing tools are inside of it. So you draw from within PinkSea and you upload it to the atmosphere. Every image that's on PinkSea is basically drawn right on it by the artists. No one can technically upload any images from elsewhere. How PinkSea got started and grew [00:01:56] Jeremy: You released this to the world. How did people find it and how many people are using it? [00:02:02] Prefetcher: I'll actually begin with how I've made it 'cause it kind of ties into how PinkSea got semi-popular. One day I was just browsing through Bluesky somewhere in the late 2024s. I was really interested in the AT Protocol and while browsing, one of the artists that I follow vertigris posted a post basically saying they'd really want to see something a drawing canvas like Drawpile or Aggie on AT Protocol or something like an oekaki board. And considering that I was really looking forward to make something on the AT Protocol. I'm like, that sounds fun. I used to be a member of some oekaki boards. I don't draw well but it's an activity that I was thinking this sounds like a fun thing to do. I'm absolutely down for it. From like, the initial idea to what I'd say was the first time I was proud to let someone else use it. I think it was like two weeks. I was posting progress on Bluesky and people seemed eager to use it. That kept me motivated. And yeah. Right as I approached the finish I posted about it as a response to vertigris' posts and people seemed to like it. I sent the early version to a bunch of artists. I basically just made a post calling for them. Got really positive feedback, things to fix, and I released it. And thanks to vertigris the post went semi-viral. The launch I got a lot of people which I would also tie to the fact that it was right after one of the user waves that came to Bluesky from other platforms. The website also seemed really popular in Japan. I remember going to sleep, waking up the next day, and I saw like a Japanese post about PinkSea and it had 2000 reposts and 3000 likes and I was just unable to believe it. Within I think the first week we got like 1000 posts overall which to me is just insane. For a week straight I just kept looking at my phone and clicking, refresh, refresh, refresh, just seeing the new posts flow in. There was a bunch of like really insane talented artists just posting their works. And I just could not believe it. PinkSea got I'd say fairly popular as an alternative AppView. People seem to really want oekaki boards back and I saw people going, oh look, it's like one of those 2000s oekaki boards! Oh, that's so cool! I haven't seen them in forever! The art stands out because it's human made [00:04:58] Prefetcher: And it made me so happy every single time seeing it. It's been since November, like four months, give or take. And today alone we got five posts. That doesn't sound seem like a lot but given that every single post is hand drawn it's still insane. People go on there and spend their time to produce their own original artworks. [00:05:26] Jeremy: This is especially relevant now when you have so much image generation stuff and they're making images that look polished but you're kind of like well... did you draw it? [00:05:39] Prefetcher: Yeah. [00:05:40] Jeremy: And when you see people draw with these oekaki boards using the tools that are there I think there's something very human and very nostalgic about oh... This came from you. [00:05:53] Prefetcher: Honestly, yeah. To me seeing even beginner artists 'cause PinkSea has a lot of really, really talented and popular people (and) also beginner artists that do it as a hobby. Ones that haven't been drawing for a long time. And no matter what you look at you just get like that homely feeling that, oh, that's someone that just spent time. That's someone that just wanted to draw for fun. And at least to me, with generative AI like images it really lacks that human aspect to it. You generate an image, you go, oh, that's cool. And it just fades away. But in this case you see people that spent their time drawing it spent their own personal time. And no matter if it's a masterpiece or not it's still incredibly nice to see people just do it for fun. [00:06:54] Jeremy: Yeah. I think whether it's drawing or writing or anything now more than ever people wanna see something that you made yourself right? They wanna know that a human did this. [00:07:09] Prefetcher: Yeah. absolutely. [00:07:11] Jeremy: So it sounds like, in terms of getting the initial users and the ones that are there now, it really all came out of a single Bluesky posts that an existing artist (vertigris) noticed and boosted. And like you said, you were lucky enough to go viral and that carried you all the way to now and then it just keeps going from there, [00:07:36] Prefetcher: Basically if not for vertigris PinkSea (would) just not exist because I honestly did not think about it. My initial idea on making something on ATProto and maybe in the future I'll do something like that would be a platform like StumbleUpon -- Something that would just allow you to go on a website, press a button, and it gets uploaded to your repo and your friends would be able to see oh -- you visited that website and there would be an AppView that would just recommend you sites based on those categories. I really liked that idea and I was dead set on making it but then like I noticed that post (from vertigris) and I'm like, no, that's better. I really wanna make that. And yeah. So right here I want to give a massive shout out to vertigris 'cause they've been incredibly nice to me. They've even contributed the German translation of PinkSea which was just insane to me. And yeah, massive shout out to every single other artist that, Reposted it, liked it, used it because, it's all just snowballed from there and even recently I've had another wave of new users from the PinkSea account. So there are periods where it goes up and it like goes chill -- and then popular again. Old internet and flash [00:08:59] Jeremy: Yeah. And so something that you mentioned is that some people who came across it they mentioned how it was nostalgic or it looked like the old oekaki BBSs from the early internet. And I noticed that that was something that you posted on your own website that you have an interest in that specifically. I wonder what about that part of the internet interests you? [00:09:26] Prefetcher: That is a really good question. Like, to me, even before PinkSea my interests lie in the early internet. I run on Twitter and also on Bluesky now an account called My Flash Archive, which was an archive of very random, like flash animations. And I still do that just not as much anymore 'cause I have a lot of other things to do. I used to on Google just type in Flash and look through the oldest archived random folders just having flash videos. And I would just go over them save all of that or go on like the dagobah or Z0r or swfchan. 'cause the early internet to me, it was really like more explorative. 'cause like now you have, people just concentrated in those big platforms like Twitter, Instagram, Facebook, whatever. And back then at least to me you had more websites that you would just go on, you would find cool stuff. And the designs were like sometimes very minimal, aesthetically pleasing. I'd named here one of my favorite sites, Kaliber10000 which had just fantastic web design. Like, I, I also spend a lot of time on like the web design museum just like looking at old web design and just in awe. My flash archive on Twitter at least got very popular. I kind of abandoned that account, but I think it was sitting at 12,000 followers if not more? And showed that people also yearn for that early internet vibe. And to me it feels really warm. Really different from the internet nowadays. Even with the death of flash you don't really have interactive experiences like it anymore. 'cause flash was supposed to be replaced by HTML5 and JavaScript and whatever but you don't really make interactive experiences that just come packaged in a single file like flash. You need a website and everything. In flash, it just had a single file. It could be shared on multiple sites and just experienced. That kind of propelled my interest. Plus I, I dunno, I just really like the old internet design aesthetics it really warms me (and really close..?) Flash loops [00:12:01] Jeremy: The flash one specifically. Were they animations or games or was there a specific type of a flash project that spoke to you? [00:12:15] Prefetcher: Something we call loops. Basically, it's sometimes animations. 'cause, surprisingly while I like flash games they weren't my main collection. What spoke to me more were loops. Basically someone would take a song, find a gif they liked, and they would just pair it together. Something like YTMND did. At least from loops I found some of my favorite musical artists, some of my favorite songs, a lot of interesting series, be it anime or TV or whatever. And you basically saw people make stuff about their favorite series and they would just share it online. I would go over those. For example, a good website as an example is z0r.de, which is surprisingly still active and updated to this day. And you would see people making loops about members of that community or whatever they like. And you would for example see like 10 posts about the same thing. So you would know someone decided to make 10 loops and just upload them at once. And yeah, to me, loops basically were like, I mean, they weren't always the highest quality or the most unique thing, but you would see someone liked something enough that they decided to make something about it. And I always found that really cool. I would late at night just browse for loops and I'm like, oh, oh, this series, I remember it. I liked it (laughs)! But of course flash games as well. I mean, I used to play a lot when I was younger, but specifically loops, even animations and especially like when someone took like their time to animate something like really in depth. My favorite example is, the music video to a song by the band Juicy Panic called Otari. Someone liked that song enough that they made an entire flash animated music video, which was basically vectorized art of various series like Azumanga Daioh or Neon Genesis Evangelion as well, and other things. And it was so cool, at least to me, like a lot of these loops just basically have an intense, like immense feeling on me (laughs). I just really liked collecting them. [00:14:38] Jeremy: And in that last example, it sounded more like it was a complete music video, not just a brief loop? [00:14:45] Prefetcher: No, it was like a five minute long music video that someone else made. [00:14:48] Jeremy: Five. Oh my gosh. [00:14:49] Prefetcher: Yeah. You would really see people's creativity shine through on just making those weird things that not a lot of people have seen, but you look at it and it's like, wow. It's different than YouTube (Sharable single file, vectorized) [00:15:01] Jeremy: It's interesting because you can technically do and see a lot of these things on, say, YouTube today, but I think it does feel a little different for some reason. [00:15:16] Prefetcher: It really is. Of course I'm not denying on YouTube you see a lot of creative things and whatever. But first and foremost, the fact that Flash is scalable. You don't lose the quality. So be able to open, I don't know, any of the IOSYS flash music videos for like their Touhou songs and the thing would just scale and you would see like in 4K and it's like, wow. And yeah, the fact that on YouTube you have like a central place where you just like put something and it just stays there. Of course not counting reuploads, but with Flash you just had like this one animation file that you would just be able to share everywhere and I don't know, like the aspect of sharing, just like having those massive collections, you would see this flash right here on this website and on that website and also on this website. And also seeing people's personal collections of flash videos and jrandomly online and you would also see this file and this file that you haven't seen it -- it really gives it, it's like explorative to me and that's what I like. You put in the effort to like go over all those websites and you just like find new and new cool stuff. [00:16:32] Jeremy: Yeah, that's a good point too that I hadn't thought about. You can open these files and you have basically the primitives of how it was made and since, like you said, it's vector based, there's no, oh, can you please upload it in 1080 p or 4K? You can make it as big as you want. [00:16:53] Prefetcher: Yeah. Web design differences, pixel art, non-responsive [00:16:55] Jeremy: I think web design as well it was very distinct. Maybe because the tools just weren't there, so a lot of people were building things more from scratch rather than pulling a template or using a framework. A lot of people were just making the design theirs I think rather than putting words on a page and filling into some template. [00:17:21] Prefetcher: Honestly, you raise a good point here that I did not think much about. 'cause like nowadays we have all of this tooling to make web design easier and you have design languages and whatnot. And you see people make really, in my opinion, still pretty websites, very usable websites on top of that. But all of them have like the same vibes to them. All of them have like a unified design language and all of them look very similar. And you kind of lose that creativity that some people had. Of course, you still find pretty websites that were made from scratch. But you don't really get the same vibes that you did get like back then. Like my favorite, for example, trend that used to be back on like the old internet is pixel art in web design. For example, Kaliber10000, or going off the top of my head, you had the Eboy or all the sites and then Poland, for example, ... (polish website) those websites use minimal graphics, like pixel graphics and everything to build really interesting looking websites. They had their own very massive charm to them that, I don't know, I don't see a lot in more modern internet. And it's also because back then you were limited by screen size, so you didn't have to worry about someone being on a Mac with high DPI or on a 32x9 monitor like I am right now. And just having to scale it up. So you would see people go more for images, like UI elements, images instead of just like building everything from scratch and CSS and whatnot. So, yeah, internet design had to accommodate the change. So we couldn't stay how it was forever 'cause technology changed. Design language has changed, but to me it's really lost its charm. Every single website was different, specific, the web design had like this weird form, at least on websites where it was like. I like to call it futuristic minimalism. They looked very modern and also very minimal and sort of dated. And I dunno, I just really like it. I absolutely recommend checking, on the web design museum fantastic website. I love them and the pixel art in web design sub page. Like those websites to me they just look fantastic. [00:19:52] Jeremy: Yeah, and that's a good point you brought up about the screen sizes where now you have to make sure your website looks good on a phone, on a tablet, on any number of monitor sizes. Back then in the late 90s, early 2000s, I think most people were looking at these websites on their 4x3 small CRT monitors. [00:20:20] Prefetcher: My favorite this website is best viewed with an 800 by 600 monitor. It's like ... what? [00:20:28] Jeremy: Exactly. Even if you open your personal site now the design is very reminiscent of those times and it looks really cool but at the same time on a lot of monitors it's a small box in the middle of the monitor, so it's like -- [00:20:49] Prefetcher: I saw that issue, 'cause I was making it on a 1080p monitor and now I have a 32x9 monitor and it does not scale. I've been working on reworking that website, but, also on the topic of my website, I, I wanna shout out a website from the 2000s that still exists today. 'cause, my website was really inspired by a website called Assembler. And Assembler, from what I could gather, was like a net art or like internet design collective. And the website still works to this day. You still had like, all of their projects, including the website that my website was based off of. [00:21:28] Jeremy: Yeah, I mean there, there definitely was an aesthetic to that time. And it's probably, like you said, it's probably people seeing someone else's site in this case, what, what did you call it? Assem? Assembler? [00:21:42] Prefetcher: Assembler. [00:21:42] Jeremy: Yeah. You see someone else's website and then maybe you try to copy some of the design language or you look at the HTML and the CSS and I mean, really at the time, these websites weren't being made with a ton of JavaScript. There weren't the minifiers, so you really could view source and just pull whatever you wanted from there. [00:22:06] Prefetcher: We also had those design studios, design agencies, notably 2advanced which check in now, their website still works, and their website is still in the same aesthetic as it was those 20 so years ago just dictating this futuristic design style that people really like. 'cause a lot of people nowadays also really like this old futurism minimalism for example a lot of people still love the Wipeout 3 aesthetic that was designed by one of my favorite studios overall the designers republic. And yeah, it's just hard for me to explain, but it feels so soulful in a way. [00:22:53] Jeremy: I think there are some trade offs. There's what we were talking about earlier with the flexibility of screen size. But there used to be with a lot of websites that used Flash, there used to be these very elaborate intros where the site is loading and there's these really neat animations. But at the same time, it's sort of like, well, to actually get to the content, it's a bit much, but, everything is a trade off. [00:23:25] Prefetcher: People had flash at their disposal and they just wanted to make, I have the tooling, I'm going to use all of the tooling and all of it. [00:23:33] Jeremy: Yeah. Yeah. but yeah, I definitely get what you're saying where when I went to make my own website I made it very utilitarian and in some ways boring, right? I think we do kind of miss some of what we used to have. [00:23:54] Prefetcher: I mean, in my opinion, utilitarian websites are just as fine. Like in some cases you don't really need a lot of flashy things and a lot of very modern very CPU intensive or whatever animations. Sometimes it is better to go on a website and just like, see, oh, there's the play button and that's it. [00:24:17] Jeremy: Yeah. Well definitely the animations and the intro and all that stuff. I guess more in terms of the aesthetics or the designs. It's tricky because there's definitely people making very cool things now things that weren't even possible back then. But it does feel like maybe the default is I'll pick this existing style sheet or this existing framework and just go with that. [00:24:47] Prefetcher: A lot of modern websites just go for similar aesthetics, similar designs, which they aren't bad, but they are also very just bland. They, they are futuristic, they are very well designed. But when you see the same website. The same -- five websites have the same feel. And this is especially, at least in my opinion, visible with websites built on top of NextJS or other frameworks. And it just feels corporate kind of dead. Like someone just makes a website that they want to sell something to you and not for fun. [00:25:26] Jeremy: With landing pages especially it's like, wow, this looks the same as every other site, but I guess it must work. [00:25:38] Prefetcher: It works. And it really cuts down on development time. You don't need to think much about it. You just already have a lot of well-established design rules that you just follow and you get a cohesive and responsive design system. Designing the PinkSea look and feel [00:25:56] Jeremy: Let's talk about that in connection with PinkSea. What was your thinking when you designed how PinkSea would look and feel? [00:26:06] Prefetcher: Honestly, at first I have to admit I looked at other websites. I looked at Bluesky first and foremost. I looked at, front page. I looked at Smoke Signal, and I thought that I might also build something that's modern and sleek and I sketched it out in an application and I showed it to some friends. One of them suggested I go for more like a 2000 aesthetic. I'm like, yeah, okay. I like that. As the website was built, I just saw more and more of how much I feel this could sit with others. Especially with the fact that it's an oekaki page an oekaki BBS and as you scroll through oekaki has a very distinct style to it. And as you scroll and you see all of those, pixel shaded, all those dithered images, non anti-aliased pens and whatnot. It feels really really cohesive somehow with the design aesthetic. But of course, PinkSea in itself is a modern website. Like if you were to go to my PinkSea repository. It's a modern website built up on top of Vue3, which talks via like XRPC API calls in real time and it's a single page app and whatever. That's kind of the thing I merged the modern way of making sites with a very oldish design language. And I feel, in my opinion, it somehow just really works. And especially it sets PinkSea apart from the other websites. It gives it that really weird aesthetic. You would go on it and you would not be like, oh, this is a modern site that connects with a modern protocol on top of a big decentralized network. This is just someone's weird BBS stuck in the 2000s that they forgot to shut down. (laughs) [00:28:00] Jeremy: Yeah. And I think that's a good reminder too, that when people are intentional about design, the tools we have now are so much better than what we used to have. There's nothing stopping us from making websites that when people go to them they really feel like something's different. I know I did not just land on Instagram. [00:28:27] Prefetcher: Yeah. And making PinkSea taught me that it's really easy to fall into that full string of thought that every site has to look modern. Because I was like, oh yeah, this is a modern protocol, a modern everything, and it has to look the part. It has to look interesting to people and everything. And after talking with a bunch of friends and other people and just going, huh, that's maybe like the 2000s isn't as bad as I thought. And yeah, the website especially it's design people seem to just really like it. Me too. I, I just absolutely love how PinkSea turned out it is really a reminder that you don't need modernness in web design always. And people really appreciate quirky looking pages, so to say, quirky like interesting. [00:29:23] Jeremy: I interviewed the, the creator of Neocities which is like kind of a modern version of GeoCities and yeah, that's really what one of the aspects that I think makes things so interesting to people from that era is, is that it really felt like you're creating your own thing, and not just everything looks the same. The term I think he used is homesteading. You're taking care of your place and it can match your sensibilities, your style, your likes, rather than having to, like you said, try to force everything to be this, this sort of base modern, look. The old spirit of the internet is coming back [00:30:08] Prefetcher: I mean Neocities and by extension also Nekoweb are websites that I often when I don't have much to do -- I like just going through them because you see a bunch of people just make their own places. And you see that even in 2025 when we have those big social media sites. You have platforms where you can get a ton of followers. You can get a ton of attention and everything. People to some extent still want that aspect of self-expression. They want to be able to make something that's uniquely theirs and you see people just make just really amazing websites build insane things on those old Geocities-like platforms using nothing but a code editor. You see them basically just wanting thing to express, oh, that's mine and no one else has it. So to say that's why. Yeah. I feel like to some extent the old school train of thought when it comes to the internet is slowly coming back. Especially with the advent of protocols like ATProto. And you'll experience more websites that just allow people to make their own homes on the internet. Cause in my opinion, one of the biggest problems is that people do not really want to register on a lot of platforms. 'cause you already have this place where you get all of your followers, you have all of your connections, and then you want to move and then you'll lose all of your connections and everything. But with something like ATProto, you can use the social graph of, for example, Bluesky. I want to add followers on PinkSea. So for example, you have an artist that has like 30,000 followers for example, I can just click import my following from Bluesky. And just like that they would already get all of the artists that they follow on Bluesky already added as followers on PinkSea. And for example, someone else joins and they followed that big artist and they instantly followed them on PinkSea as well. I think that we are slowly coming back to the advent of people owning their place online. PinkSea and ATProto (PDS) [00:32:24] Jeremy: Yeah. So let's talk a little bit more about how PinkSea fits into ATProto. For people who aren't super familiar with ATProto, maybe you could talk about how it's split up. You've got the PDS, the relays, the AppView. What are those and how do those fit into what PinkSea is? [00:32:48] Prefetcher: My favorite analogy, ATProto is a massive network, and at least me, when I saw the initial graph I was just very confused. I absolutely did not know what I'm looking at. But let's start with the base building block, something that ATProto wouldn't exist with. And it's the PDS. Think of the PDS as like a filing cabinet. You have a bunch of folders in which you have files, so to say. So you have a filing cabinet with your ID, this is the DID part that sometimes shows up and scares people. It's what we call a decentralized identifier. Basically that identifier is not really tied to the PDS, it just exists somewhere. And the end goal is that every user controls their DID. So for example, if your PDS shuts down, you can always move to somewhere else. Still keep like, for example, that you are prefetcher.miku.place. But in that filing cabinet the PDS going back to it you have your own little zone, your own cabinets, and that has your identifier, it's uniquely yours. Every single application on the AT protocol creates data. They create data and they store the data in a structured format called a record. A record is basically just a bunch of data that explains what that thing is, be it a like, a post on Bluesky an oekaki on PinkSea and an upvote on front page, or even a pixel on place.blue. And all of those records are organized into folders in your cabinet. And that folder is named with something we call a collection id. So for example, a like is, if I remember correctly, it's app.bsky.feed.like, so you see that it belongs to Bluesky. The app.bsky part. it's a feed thing, and the same way, PinkSea, for example, the oekaki and PinkSea uses com.shinolabs.pinksea.oekaki with com.shinolabs being the the collective that I use as a, pen name, so to say. PinkSea being, well, PinkSea and oekaki just being the name. It's an oekaki. If you want to see that there are a lot of tools, for example, PDSls or atp.tools or ATProto browser, if you had to go into one of those and you would type in for example, prefetcher.miku.place, you would see all of your records, the things that, you've created on the AT protocol network. Relay [00:35:19] Prefetcher: So you have a PDS, you have your data, but for example, imagine you have a PDS that you made yourself, you hosted yourself. How will, for example, Bluesky know that you exist? 'cause it won't, it's just a server in the middle of nowhere. That's where we have a relay. A relay is an application that listens to every single server. So every time you create something or you delete something, or for example, you edit a post, you delete an oekaki. You create a new, like -- Your PDS, your filing cabinet generates a record of that. It generates an event, something we call a commit. So, anytime you do something, your PDS goes, Hey, I did that thing. And relays function as big servers that a PDS can connect to. And it's a massive shout box. The PDS goes, Hey, I made this. Then the relay aggregates all of those PDSs into one and creates a massive stream of every single event that's going on the network at once. That's also where the name firehose comes from. 'cause the, the end result, the stream is like a firehose. It just shoots a lot of data directly at anyone who can connect to it. And the thing that makes AT Protocol open and able to be built on is that anyone can just go, I want to connect to jetstream1.west.bluesky.network. They just make a connection to it and boom they just get everything that's happening. You can, for example, see that via firesky.tv. If you go to it, you would open it in your browser. Every single Bluesky post being made in real time right directly in your computer. So you have the PDSs that store data, you have the relay that aggregates every, like, builds a stream of every single event on the network. AppViews [00:37:26] Prefetcher: You just get records. You can't interact with it. You can see that someone made a new record with that name, but to a human, you won't really understand what a cid is or what property something else is. That's why you have what we call AppViews. An AppView, or in full an application view is an application that runs on the AT protocol network. It connects to the relay and it transforms the network into a state that it can be used by people. That's why it's called an application view. 'cause it's a, a specialized view into the whole network. So, for example, PinkSea connects, and then it goes, hey, I want to listen on every single thing that's happening to com.shinolabs.pinksea.oekaki, and it sees all of those, new records coming in and PinkSea understands, oh, I can turn it into this, and then I can take this thing, store it in the database, and then someone can connect with a PinkSea front end. And then it can like, transform those things, those records into something that the front end understands. And then the front end can just display, for example, the timeline, the same way Bluesky, for example -- Bluesky gets every single event, every single new file, new record coming in from the network. And it goes. Okay, so this will translate into one more like on this post. And this post is a reply to that post. So I should chain it together. Oh. And this is a new feed, so I should probably display it to the user if they ask for feeds. And it basically just gets a lot of those disjoint records and it makes sense of them all. The end user has a different API to the Bluesky AppView. And then they can get a more specialized view into Bluesky. PinkSea does not store the original images, the PDS does [00:39:26] Jeremy: And so in that example, the PDSs, they can be hosted by Bluesky the company, or they could be hosted by any person. And so PinkSea itself, when somebody posts a new oekaki, a new image, they're actually telling PinkSea to go create the image in the user's PDS, right? PinkSea is itself not the the source of truth I guess you could say. [00:40:00] Prefetcher: PinkSea in itself. I don't remember which Bluesky team member said it, but I like the analogy that AppViews are like Google. So in Google, when you search something, Google doesn't have those websites. Google just knows that this thing is on that website. In the same vein, PinkSea, when you create a new oekaki, you tell PinkSea, Hey, go to my PDS and create that record for me. And then the person owns the PDS. So for example, let's say that in a year, of course I won't do it, but hypothetically here, I just go rogue and I shut down PinkSea, I delete the database. You still own the things. So for example, if someone else would clone the PinkSea repository and go here, there's PinkSea 2. They can still use all of those images that were already on the network. So, AppViews in a way basically just work as a search engine for the network. PinkSea doesn't store anything. PinkSea just indexes that a user made a thing on that server. And here I can show you how to get to it somehow. Those images aren't stored by PinkSea, but instead, I know that the image itself is stored, for example, on pds.example.com, and of course to reduce the load, we have a proxy. PinkSea asks the proxy to go to pds.example.com and fetch the image, and then it just returns it to the user. [00:41:37] Jeremy: And so what it sounds like then is if someone were to create oekaki on their own PDS completely independently of Pink Sea the fact that they had created that image would be sent to one of the relays, and then PinkSea would receive an event that says oh, this person created a new image then at that point your index could see, oh, somebody created a new image and they didn't even have to go through the PinkSea website or call the PinkSea APIs. Is that right? Sharing PDS records with other applications [00:42:14] Prefetcher: Yep. That is exactly right. For example, someone could now go, Hey, I'm making my own PinkSea-like application. And then they would go, I want to be compatible with PinkSea. So I'm using the same record. Or what we call a lexicon, basically describe how records look like. I forgot to mention that, but every single record has an attached lexicon. And lexicons serve as a blueprint. So a lexicon specifies, oh, this has an image, this has a for example, the tags attached to it, a description of the image. Validate that the record is correct, that you don't get someone just making up random stuff. But yeah, someone could just go, Hey, I'm making another website. Let's call it GreenForest for example. And GreenForest is also an oekaki website, but it uses, for example, chickenpaint instead of tegaki but I want to be able to interoperate with PinkSea. so I'm also gonna use com.shinolabs.pinksea.oekaki the collection, the same record, the same lexicon. And for example, they have their own servers and the servers just create regular oekaki records. So for example, GreenForest gets a new user, they log in, create, draw their beautiful image, and then they click upload it. So GreenForest goes to that person's PDS and tells the PDS, Hey, I want to make a new. com.shinolabs.pinksea.oekaki record. The PDS goes okay, I've done it for you. Let me just inform the relay that I did so, relay gets the notification that someone made that new PinkSea oekaki record. And so the main PinkSea instance, pinksea.art, which is listening in on the relay, gets a notification from the relay going, Hey, there is this new oekaki record. And PinkSea goes, sure, I'll index it. And so PinkSea just gets that GreenForest image directly in itself. And in the same vein, someone at PinkSea could draw something in tegaki -- their own beautiful character. And the same thing would happen with GreenForest. GreenForest would get that PinkSea image, that PinkSea record, and index it locally. So the two platforms, despite being completely different, doing completely different things, they would still be able to share images with each other. Bluesky PDS stores other AppView's data but they could stop at anytime [00:44:38] Jeremy: And these images, since they're stored in the PDS, what that would mean is that anybody building an application on ATProto, they can basically use Bluesky's PDS or the user's PDS as their storage. They could put any number of images in there and they could get into gigabytes of images. And that's the responsibility of the PDS and not yourself to keep track of. [00:45:12] Prefetcher: Yes, that can be the case. Of course, there is a hard limit on how big a single upload can be, which is, if I remember correctly, I don't wanna lie, I think it's 50 megabytes, I don't recall there being a hard cap on how big a single repository can be. I know of some people whose repositories are in the single gigabyte digits but this kind of is a thing scares app developers. 'cause you never know when Bluesky the company -- 'cause most people registering, are registering on Bluesky. We don't really know whether Bluesky, the company will want to keep it for free. Forever allow us to do something like that. You already have projects like, for example, ATFile, which just allow you to upload any arbitrary data just to store it, on their servers and they are paying for you. So we'll never know whether Bluesky will decide, okay, our services are only for Bluesky if you want to use PinkSea you have to deal with it. Or whether they go, okay, if you want to use alternative AppViews you have to pay us in order to host them. So, that also leads me to the fact that decentralization is an important part of AT protocol as Bluesky themselves say that they are a potential adversary. You cannot trust them in the long term. Right now they are benign right now, they're very nice, but, we never know how Bluesky will end up in a year or two. So if you want to be in the full control of your data, you need to sadly host it by yourself. And it's honestly really easy in order to do so. There is a ton of really useful online content blogs and whatever. I think I've set up my PDS in 10 minutes on a break between classes and university. But to a person that's non-technical that doesn't know much I'd say around an hour to two hours The liability and potential abuse from running a PDS [00:47:14] Jeremy: Yeah, I think the scary thing for a lot of people is technical or not, is even if it's easy to set up, you gotta make sure it keeps running. You gotta have backups. And so it could be a lot. [00:47:30] Prefetcher: Yeah. This is to be expected by the fact that you're in control of your data. Keeping it secure the same way, for your personal photos or your documents, for example, your master's diploma or whatever. And it's on you to keep your Bluesky interaction secure. On one hand, it's easier to get someone to do it, and I expect in the future we'll get people that are hosting public PDSes I sometimes thought of doing that for PinkSea, just like allowing people to register by PinkSea. But, doing so as a person, you also have to be constantly on call for abuse. So if someone decides to register via PinkSea and do some illicit activities, you are solely responsible for it. PDS and AppView moderation liability [00:48:17] Jeremy: So if they were to upload content that's illegal, for example, it's hosted on your servers so then it's your problem. [00:48:27] Prefetcher: Yeah, it is my problem. [00:48:29] Jeremy: At least the way that it works now, the majority of the people, their PDS is gonna be hosted by Bluesky. So if they upload content that's breaks the law, then that's the Bluesky company's problem at least currently. [00:48:44] Prefetcher: Yeah. That is something that Bluesky has to deal with. But I do believe that in the future we are going to have, more like independent entities just building infrastructure for ATProto, not even the relay it's just like PDSs for people to be able to join the atmosphere, but not directly via Bluesky. [00:49:06] Jeremy: I'm kind of curious also with the current PDSs, if it's hosted by Bluesky, are they, are they moderating what people upload to their PDSs? [00:49:16] Prefetcher: Good question. Honestly, I don't think they're moderating everything 'cause, it's infeasible for them to, for example, other than moderate Bluesky to also moderate PinkSea and moderate front page and whatnot. So it's the obvious responsibility to moderate itself and to report abuse. I'd say that if someone started uploading illicit material, I do not think, and this is not legal advice, I do not think that they would catch on until some point let's say. [00:49:52] Jeremy: I mean, from what you were describing too, it seems like the AppViews would also, have issues with this because if, let's say someone created a PinkSea record in their PDS directly and the image they put in was not an oekaki image, it's instead something pretty illegal in the country that your AppView is hosted then, Wouldn't that go straight to the PinkSea users viewing the website? [00:50:20] Prefetcher: Yes, sadly, this is something that you have to sign up as you're making an AppView and especially one with images. Sooner or later you are going to get material that you have to moderate and it's entirely on you. That's why, you have to think of moderation while you're working on an AppView. Bluesky has an insanely complicated, at least in my opinion, moderation system, which is composable and everything, which I like. But for smaller AppViews, I think it's too much to build the same level of tooling. So you have to rely more on manual work. Thankfully so far the user base on PinkSea has been nothing but stellar. I didn't have to deal with any law breaking stuff, but I am absolutely ready for one day where I'll have to sadly make some drastic moderation issues. [00:51:18] Jeremy: Yeah. I think to me that's the most terrifying thing about making any application that's open to user content. [00:51:29] Prefetcher: I get it, sadly. I'm no stranger to having issues with people, abusing my websites. Because since 2016, my, first major project was a text board based off of, a text board in a video game called DANGER/U/. It was semi-popular, during the biggest spike in activity in like 2017 and 2016, it had in the tens of thousands of monthly visitors. And sadly, yeah, even though it was only text, I've had to deal with a lot of annoying issues. So to say the worst I think was I remember waking up and people are telling me that DANGER/U/ is down. So I log in the activity logs and someone hit me with two terabytes of traffic in a day. There was a really dedicated person that just hated my website and just either spam me with posts or just with traffic. So, yeah, sadly I have experience with that. I know what to expect that's something that you sadly have to sign up for making a website that allows user content. Pinksea is a single server [00:52:42] Jeremy: To my understanding so far, PinkSea is just a single server. Is that right? [00:52:47] Prefetcher: It is a single server. Yeah. [00:52:48] Jeremy: That's kind of interesting in that, I think a lot of people when they make a project, they worry about scaling and things like that. But, was it a case where you just had a existing VPS and you're like, well hopefully this is, this is good enough? [00:53:03] Prefetcher: I actually ordered a new one even though it's not really powerful, but my train of thought was that I didn't expect it to blow up. I didn't expect it to require more than a single VPS with 8 gigabytes of RAM and whatnot. And so far it's handling it pretty well. I do not expect ever to reach the amounts of traffic that Bluesky does, so I do not really have to worry about insane scalability and whatever. But yeah. I thought of it always as a toy project until the day I released it and realized that it's a bit more than a toy project at this point. To this day, I just kind of think that that website even if it were popular, I would never expect it to have -- And in the best, most amazing case scenario, like a hundred posts a day. I do not have to deal with the amount of traffic that Bluesky does. So one VPS it is. [00:53:59] Jeremy: Yeah, that makes a lot of sense. I mean the application is also mostly reads, right? Most people are coming to see the posts and like you said, you get a few submissions a day, but all the read stuff can probably be cached. Harbor image proxy [00:54:15] Prefetcher: Yeah. The heaviest, thing that PinkSea requires is the image proxy harbor, and that's something that right now only runs on that server. It's in Luxembourg. I think that's where my coprovider hosts it but yeah, that gets the most reads. 'cause in most cases, PinkSea, all it does, all you get is reads from a database, which is just, it's a solved problem. It's really lightweight. But with something like image proxying, you have this whole new problem. 'cause it's a lot of data, and you somehow have to send it -- it's enough for me to just host it locally on that PinkSea server and just direct people to it. But sooner or later, I can always just put it behind something like Bunny CDN or whatnot to have it be worldwide. [00:55:09] Jeremy: So Harbor is something I think you added recently. How did the images work before and what is Harbor doing in its place? [00:55:18] Prefetcher: Before I did what a lot of us currently do and I just freeload atop of Bluesky CDN 'cause Bluesky CDN is just open so far. But it's something that personally irked me. 'cause, I want PinkSea to be completely independent of Bluesky Corporation. I, I wanted to persevere even if Bluesky just decides to randomly, for example, close, the CDN to others or the relay to others or the PLC directory in the worst case scenario. So I wanted to make my own CDN more like proxy. You can't really call it a CDN because it's not worldwide. It's just a single server but let's just say image proxy. So Harbor whenever a person goes to PinkSea, they start loading in all of the images and every single image instead of going to, for example, the PDS or to cdn.bluesky.app. They go to harbor.pinksea.art, you get attached the identifier of the user and what we call a content identifier. Every single, thing uploaded to a PDS has an attached content identifier, which identifies it in a secure way so to say. So Harbor does in reality a really simple set of things. First and foremost, if the user has not seen it, like, not loaded it before first Harbor asks the local cache, do I have this file? If they do, if Harbor does, it just sends the file and it tells the browser, Hey, by the way, please don't ask me about this file for the next day. And in most cases, after one refresh, the user, all of the images load instantly because the web browser just goes, of those files were already sent. And Harbor asked me not to like, ask it more about the same file. So in the case of the image isn't in harbor's local cache, Harbor, first does a lot of those steps to resolve, the users identifier through their PDS, basically resolving that identifier, the DID to a DID document, which is a document basically explaining how that user, what is their, alias, what is their handle and where can we find them, which PDS. So we find the PDS and we then ask the PDS, Hey, send us this file for this user. The PDS sends it or doesn't, in which case we just throw an error and, Harbor just saves it locally and it sends it to the client. It basically just that. But to my knowledge, it's the first non Bluesky image proxy that's deployed for any AppView. Which also caught the attention of Brian Newbold one of the Bluesky employees and made me really happy. DID PLC Lookup [00:58:14] Jeremy: The lookup when you have the user's, DID and you wanna find out where their PDS is that's talking to something called, I think it's the PLC directory? [00:58:25] Prefetcher: Actually there are two different ways. First is PLC directory, PLC originally standed for a placeholder, and then Bluesky realized that it's not a placeholder anymore, and they stealthily changed it to public ledger of credentials. So we have PLC and we have web, the most common version is PLC. The document, the DID document is stored on Bluesky controlled servers under the moniker of PLC directory. They expose a web API that basically just allows you to say, Hey, give me the document for did:plc, whatever. And, the directory goes, have it. And this is the less decentralized version. You can host your own PLC directory and you can basically ask (their) PLC directory to just send you every single document and just you can have your local copy, which some people already do, you kind of sacrifice the fact that you are not in control of the document. It's still on a centralized server, even if you control the keys. 'cause every single DID document also has a key. And that key is used to sign changes to the document. So technically, if you define your own set of keys, you can prevent anyone else from modifying your document, even Bluesky. 'cause every single document is verifiable back and forth. You can see the previous document and its key is used to sign the next document and the chain of trust is visible and no one can just make random changes to your identity, but yeah, it's still on Bluesky to control service and it's a point of contention. Bluesky eventually wants to move it to a nonprofit standards organization, but we have yet to see anything come out of it, sadly. DID WEB lookup The next method is web. And web instead of -- 'cause in did:plc, you have did:plc, and a random string of characters. [01:00:30] Prefetcher: Web relies on domains. So for example, the domain would already like be the sole authority of where the file is. So for example, if I had did:web:example.com, I would parse the DID and I would see it's hosted at example.com. So I go to example.com, I go to /.wellknown/did.json which is the well-known location for the file. And I would have the same DID document as I would have if I used, for example, a PLC DID resolved via the PLC directory. the web method, you are in control of the document entirely. It's on your server under your domain. While it's the more decentralized version, it's just kind of hard for non-technical people to make them. 'cause it relies on a bunch of things. And also the problem is that if you lose your domain, you also lose your identity. [01:01:23] Jeremy: Yeah. So unlike the PLC where it's not really tied to a specific domain, you can change domains. With the web way, you have to always keep the same domain 'cause it's a part of the DID and yeah, like you said, you can't let your renewal lapse or your credit card not work. 'cause then you just lose everything. [01:01:49] Prefetcher: Yeah. You would still be able to change handles, but you would be tied for that domain to forever send your DID otherwise you would just lose it forever. [01:01:57] Jeremy: Yeah, I had mostly only seen the PLC and I wasn't too familiar with the web, form of identification, but yeah that makes sense. [01:02:06] Prefetcher: I think the web if I remember correctly, there is slightly over 300 accounts total on the entire network that use it. Mary who is a person on Bluesky that does a lot of like, ATProto related things, has a GitHub repository that basically gives insight into the network. And on her GitHub repository, you can find the list of every single custom PDS and also how many DID webs there are in existence. And I think it was slightly over 300. [01:02:38] Jeremy: So are you on that list? [01:02:40] Prefetcher: My PDS Yeah. If you were to scroll down. I don't use a web DID 'cause I registered my account before when I was brand new to ATProto, so I didn't know anything. But if you had to scroll down, you would see pds.ata.moe, which is my custom PDS just running. [01:02:55] Jeremy: Cool. [01:02:57] Prefetcher: Yeah. Harbor image proxy can cache any image blob [01:02:58] Jeremy: So something I noticed about harbor, you take the, I believe you take the DID and then you take the CID, the content identifier. I noticed if you take any of those pairs from the ATProto network, like I go find a image somebody posted on Bluesky, I pass that post DID and CID for the image into harbor. Harbor downloads it and caches it. So it's like, does that mean anybody could technically use you as a ATProto CDN? [01:03:38] Prefetcher: Yes, the same way anyone could use like the Bluesky CDN to for example, run PinkSea like I did. cause I do not know if there is a good way to check if a CID of an image or a blob basically. 'cause files on ATProto are called blobs. I do not think there is a nice way to check if that blob is directly tied to a specific record. But that also allows you to make cool, interesting things. Crossposting to Bluesky talks directly to the PDS [01:04:06] Prefetcher: 'cause for example, PinkSea has that, cross post to Bluesky thing. So when you create an image, You already have an option to cross post it to Bluesky, which a lot of people liked. And it was a suggestion from one of the early users of PinkSea. And the way it works is that when we create a PinkSea record, we upload that image, right? And then PinkSea goes, okay, I'm gonna use that same image, the same content identifier, and just create a Bluesky post. So Bluesky and PinkSea all share the same image. I don't upload it twice, I just upload it once. use it in PinkSea and I also use it in Bluesky. And the same way Bluesky its CDN, can just fetch the image. I can also fetch the image from mine, 'cause blobs aren't tied to specific records. They just exist outside of that realm. And you could just query anything. Not even images. You could probably query a video or even a text file. [01:05:04] Jeremy: So when you cross post to Bluesky, you're creating a record directly in the person's PDS, not going through bluesky's API. [01:05:14] Prefetcher: No, I sidestep Bluesky's API completely. And, I basically directly talk to the PDS at all times. I just tell them, Hey, please, for me, create a app.bsky.feed.post record. And you have the image, the text, which also required me to manually parse text into rich text. 'cause like, Bluesky doesn't automatically detect for example, links or tags And you basically get -- like PinkSea creates a record directly with the link to the image. And all of those tags, like the PinkSea tag and whatever, And I completely sidestep. Bluesky's API. If Bluesky, the AppView would cease to exist, PinkSea would still happily create Bluesky crossposts for you. Other applications put metadata into Bluesky posts so they can treat them differently [01:06:02] Jeremy: And since you're creating the records yourself, then you can include additional metadata or fields where you know that this was a PinkSea post, or originally came from PinkSea. [01:06:13] Prefetcher: I could do that. I don't really do that right now 'cause I don't really have much of a reason other than adding a PinkSea hashtag to every single oekaki. But I, noticed, for example, I think it was PinkSky, interesting name, PinkSky, which is like (a) Bluesky Instagram client. Any single time you make a post via PinkSky it uses the Bluesky APIs. It's Bluesky, but it attaches a hidden hashtag like PinkSky underscore some random letters. In its feed building algorithm, it basically detects posts with that hashtag, that specific hashtag, and it builds a PinkSky only timeline. 'cause it's still a Bluesky post, but it has hidden additional metadata that identifies, Hey, it came from PinkSky. [01:07:02] Jeremy: It's pretty interesting how much control you have over what to put in the PDS. So, I'm sure there's a lot of interesting use cases that people are gonna come up with. [01:07:14] Prefetcher: Yeah, of course. You still lose some of the data when you go through the Bluesky API. 'cause of course it stores the record and it's all in formats and whatnot. But you can attach a lot of metadata that can identify posts and build micro networks within Bluesky itself. I see it like that. Bluesky CDN compression [01:07:37] Jeremy: And I think, this might have been a post from you. I think I saw somebody saying that when you view an image from the CDN that the Bluesky CDN specifically, there's some kind of compression going on that that messes with certain types of art. [01:07:55] Prefetcher: It's especially noticeable artists are complaining about it all the time, left and right. Bluesky is very happy with jpeg compression, by default, their CDN, -- like to every single image it applies a really not good amount of jpeg compression which is especially not small. If you compare an image that's uploaded via PinkSea, view an image on PinkSea, and view the same image, which is, it's the same content id. It's the same blob. And you view it on Bluesky, it loses so much fidelity, it loses so much of that aliasing on the pen. You just see everything become really blurry. And on top of that, when you upload an image via Bluesky itself, if I remember correctly, I don't wanna lie here, but they also downscale the image to 1024 pixels by default. So every single image, not only big ones, and artists usually work with really big canvases, they get, downscaled and also additionally they get jpegified. So for example, PinkSea directly uploads PNG files to the PDS. And for example, Harbor gives back the original file. It does no transformations on it, but Bluesky transforms all of them into JPEG compressed images and for photos, it's fine sometimes. 'cause I've also seen people just compare directly, downloaded images of the PDS versus images viewed on Bluesky. But for art it's especially noticible. And people really (do) not like that. [01:09:31] Jeremy: Yeah, that's kind of odd. 'cause if, if I understand correctly, then if you post directly to your PDS and Bluesky pulls it in you'll avoid that, that 1024 resizing. So your images will be higher quality? [01:09:47] Prefetcher: I actually do not know. That's an interesting question. Cause I know that the maybe their CDN also does that 'cause that's what I've heard from others, that on upload the image gets processed and squashed down. So I don't know if doing it via an alternative AppView would change it or would Bluesky just directly reject this post? Because for example, PinkSea, I have built-in which I think I might change in the future -- PinkSea will reject your post if it's bigger than 800x800. 'cause then it'll notice that something is off. This could not have been made with PinkSea. [01:10:26] Jeremy: Yeah, that's a good point I suppose we know at the very least, they have some third party and internal moderation tools that they feed the images through to, so they, they can do some automatic content tagging. But yeah, I, I don't know, like you said, whether, the resizing and all that stuff is at the CDN level [01:10:50] Prefetcher: The jpegification is definitely at the CDN level. 'cause, Bluesky is actually running an open source image proxy. It's called imgproxy. Brian Newbold talked about it a bit on that harbor post. And, yeah, so a lot of the compression, the end user things are done via image proxy, but that, downscaling, I don't know, you'd have to ask someone who's a bit more intimate with Bluesky's internals. [01:11:19] Jeremy: Cool. yeah, I think we've, we've covered a lot. Is there, is there anything else, you wanted to mention or thought we should have talked about? [01:11:26] Prefetcher: Regarding PinkSea I think I've mentioned a ton both the behind the scenes things and, the user things, the design principles. What I'd want to absolutely say, and it will sound cheesy, and, is that I'm eternally grateful to anyone who's actually visited PinkSea. It's definitely grown outta all of my like dreams for the platform, to the point where I'm sitting here just talking about it. I definitely hope that the future will bring us more applications (in) ATProto. I definitely have ideas on how to expand PinkSea, a lot of ideas, a lot of things I want to do, and I'm also a very busy person, so I never get around them. But yeah, think that's it, at least regarding PinkSea. [01:12:15] Jeremy: Cool. Well, if people want to check out PinkSea or see what you're up to, where can they find you? [01:12:22] Prefetcher: So PinkSea is at pinksea.art. That's the website and Bluesky Handle is at pinksea.art and me, well, search prefetcher on Bluesky, you'll probably find me. My tag is at prefetcher.miku.place. all of my socials are probably there. I'm Prefetcher pretty much every single platform except for the platforms that already had someone called Prefetcher. GitHub, github.com/purifetchi because Prefetcher was taken. And, yeah, hit me up. I'm always eager to talk. I don't bite. [01:13:00] Jeremy: Very cool. Well, Kacper thanks. Thanks for taking the time. This was fun. [01:13:04] Prefetcher: Thank you so much, Jeremy, for having me over. It was a pleasure.

Bonjour à tous!

durée : 01:04:56 - Les Nuits de France Culture - par : Albane Penaranda, Mathias Le Gargasson, Antoine Dhulster - À Amiens, Edward Bond participe à un atelier de théâtre avec des lycéens. C'est l'occasion pour lui de dire combien il apprécie la simplicité mais aussi l'intelligence, l'intuition et surtout la liberté des jeunes qui contrastent avec notre emprisonnement face aux problèmes du monde. - réalisation : Massimo Bellini - invités : Edward Bond Dramaturge et metteur en scène britannique; Jérôme Hankins Maître de conférences en Études théâtrales à L'université de Picardie Jules Verne (Amiens), traducteur, directeur artistique de l'Outil compagnie (dans la Somme).; Bruno Tackels Essayiste et dramaturge. Agrégé et docteur en philosophie, ancien enseignant d'esthétique et d'histoire du théâtre contemporain.

Heute tauchen wir tief in die Transformation von Kernsystemen in der Versicherungsbranche ein. Unsere Gastgeber begrüßen Thorsten Vogel, Partner bei BearingPoint, der uns spannende Einblicke in die Herausforderungen und Erfolge von Modernisierungsprojekten gibt. Wir diskutieren die Notwendigkeit, ältere Systeme schnell zu ersetzen, den Einfluss von Compliance-Problemen und die Bedeutung wettbewerbsfähiger IT-Landschaften. Zudem erfahren wir, wie Standardsoftware und maßgeschneiderte Lösungen die Prozessoptimierung vorantreiben können. Freut Euch auf interessante Ergebnisse aus einer umfassenden Studie mit rund 250 Kernsystem-Implementierungen und nützliche Tipps für eine erfolgreiche Transformation.Schreibt uns gerne eine Nachricht!Folge uns auf unserer LinkedIn Unternehmensseite für weitere spannende Updates.Unsere Website: https://www.insurancemondaypodcast.de/Du möchtest Gast beim Insurance Monday Podcast sein? Schreibe uns unter info@insurancemondaypodcast.de und wir melden uns umgehend bei Dir.Vielen Dank, dass Du unseren Podcast hörst!

About Bill Hinshaw and Cobol Cowboys: Experienced Founder and CEO with a demonstrated history of working in the information technology industry. Proven expertise in systems architect, development, integration and support of mainframe software for banking and state government. Experienced in starting companies for software design, development, support and deliverables. Highly skilled in COBOL, CICS, DB2, VSAM, MQ, Assembler and related mainframe and server products. Expert witness in matters related to systems integration vs. database interfaces. Testified at State of New Jersey Senate Hearings on Unemployment Claims. AI advisory role for debugging & documenting COBOL programs. Strong business professional — attended Indiana University-Purdue University at Indianapolis, Indiana. Appointed Director of Data Processing by Governor of Indiana to implement mainframe computer services. Founded and headquartered in North Texas, Cobol Cowboys provides professionals for legacy COBOL systems and other programming environments. Our name, Cobol Cowboys, was inspired by the movie “Space Cowboys” in which experienced (some retired) astronauts were called back into service to solve a current day problem in outer space. After researching many published articles (both positive and negative) on the future life of COBOL, we came away with renewed confidence in its continued life in the coming years. Since COBOL is still the programming foundation and under-structure used today in most USA and International companies, we founded Cobol Cowboys in North Texas to provide professionals for legacy COBOL Systems and non-COBOL systems. This renewed confidence in COBOL is supported by IBM's strategies to keep COBOL robust and evergreen as a viable programming language today and years to come. These strategies are evidenced by IBM's continued enhancements which allow COBOL and Java to run together on mainframes and to take advantage of the latest industry-driven database products (such as DB2 and SQL). Furthermore, COBOL has been enhanced to develop “object oriented” code in addition to its time-proven legacy code still in use today. These and other programming enhancements offered by IBM keep COBOL a state-of-the-art programming solution. We offer experienced COBOL (and other software) professionals in various vertical markets; including banking, government, insurance, health care, manufacturing, warehousing, transportation and others.

Before founding DH Property Holdings, Dov was the Executive Vice President of Acquisitions of Asset Management at Extell Development Company. During his 13+ years at Extell, Dov negotiated and supervised the acquisitions of over $20 billion of New York real estate. Dov was directly responsible for sourcing some of the most notable transactions over the last 10 years, including The Ring Portfolio, One 57, Nordstrom Tower, and One Manhattan Square. We discuss: Stories from Dov's career assembling iconic NYC sites Pivoting to Class B Industrial How to Negotiate in RE We'd appreciate you filling out our audience survey, so we can continuously work on providing relevant content to our listeners.  https://www.thefortpod.com/survey Topics (00:00:00) - Intro (00:01:56) - Dov's early career  (00:05:02) - Land assemblage and zoning in NYC (00:13:12) - Tenant risks (00:16:06) - Assembling Central Park Tower site (00:27:21) - Assembling 1 Manhattan Square site (00:32:45) - The Ring portfolio (00:48:19) - Hiring Japanese actors to finalize a deal (00:56:42) - Venturing into Class B Industrial (01:13:58) - How would outsiders perform in NYC trying to assemble land? (01:15:00) - The power of negotiation Links DH Property Holdings More on Dov Hertz Dov in The Real Deal Dov in Crain's New York Business Dov's Real Estate Investment Blog Support our Sponsors Relay Human Cloud: https://bit.ly/3sjQcaY Fort: https://bit.ly/FortCompanies Follow Fort on LinkedIn: https://www.linkedin.com/company/fort-companies/ Chris on Social Media: X: https://bit.ly/3BYIjcH LinkedIn: https://bit.ly/45gIkFd   Watch The Fort on YouTube: https://bit.ly/3oynxNX Visit our website: https://bit.ly/43SOvys Leave a review on Apple: https://bit.ly/45crFD0 Leave a review on Spotify: https://bit.ly/3Krl9jO  The FORT is produced by Johnny Podcasts

"Bboy Techno with Davy Wreck aims to create a captivating energizing sonic journey, fusing diverse electronic genres to make bodies move and spirits groove. Each episode will showcase my genre-bending sound of Dance Music, drawing inspiration from my rich background in Breakdancing, Producing, & Design. " Tracklist "Mizzo - Bringing 88 back Sofie superflying jackson - Doshys boomin kotti vibes Sellrude - That's movement Data theft - Data loss RHR - Na capture DAWL - System check Parasit - Elektrotechnik Yarnit - Ibs Davy Wreck - Shoot for the stars (unreleased) Dj naughty - Your Man (Dj Swisha bootleg) Assembler code - Architects XO-5 - Technologic Davy Wreck - Million dollar break DJ Godfather - Decifer the code K_Schreiber - Zanzibar Davy Wreck - Rave at 8 Club cab - Space case Sketchy - Hit em with the low cut"

Welcome back Kacey and welcome in Matt. Matt served in the Navy. So naturally we have lot of questions about the food he ate and the best part about being in the Navy. We also ask him what his reaction was when he found out when he was deploying and to where he was deploying. Then he talks to us about his journey on his road to hope. 

Ein Leitspruch für die Frontend-Welt: Make simple things simple and complex things possibleDie Frontend-Entwicklung hat in den letzten Jahren einen ziemlich großen Wandel erlebt. Es fing alles ganz simpel an: CSS und JavaScript wurden einfach via script-tag inkludiert. Danach kamen Performance-Optimierung durch Minification, mehr JavaScript- und CSS Features (zB Browser-APIs) wurden in die Browser implementiert und die Standards kamen nicht hinterher, doch wir Entwickler*innen wollten wir diese schon in Produktion nutzen (aka Polyfills und Transpilieren). Und auch die Web-Apps wurden immer mehr “Desktop-Like”, was einen Effekt auf die Frontends von heute hat, zB. React, Vue und Co. Und wo sind wir heute? Frameworks wie HTMX, die mit Einfachheit werben, erleben einen neuen Hype.Doch ist das alles neu oder nur “alter Wein in neuen Schläuchen”? Erkaufen wir uns durch diesen großen Tooling-Stack wirklich Einfachheit oder schließen wir uns durch die Komplexität doch nicht in eine "proprietäre API” ein, die es sehr schwer macht, das Framework zu wechseln? Und zu guter letzt: Ist die Komplexität gerechtfertigt?Zu diesem Thema sprechen wir mit Golo Roden. Golo ist Frontend-Experte und spezialisiert auf native Webtechnologien. Mit ihm behandeln wir Themen wie die Probleme von aktuellen UI-Frameworks und woher diese Probleme eigentlich kommen, wie er zu einfacheren Konzepten wie HTMX steht, über mögliche Lösungsansätze für die Probleme, Standards wie Web Components und welche Rolle TypeScript in dem ganzen Mix einnimmt.Bonus: Warum Monkey Island das richtige Spiel für dich und deine Kinder ist.**** Diese Episode wird von der HANDELSBLATT MEDIA GROUP gesponsert.Wirtschaft ist nicht immer einfach. Deswegen lautet die Mission der HANDELSBLATT MEDIA GROUP: „Wir möchten Menschen befähigen, die Wirtschaft zu verstehen.“ Mit ihren Kernprodukten, dem Handelsblatt und der WirtschaftsWoche, sowie 160.000 Abonnements, 15 Millionen Besuchern und 3 Milliarden Anfragen in einem Monat leisten sie einen wichtigen Beitrag zur Orientierung und Meinungsbildung in den Bereichen Wirtschaft und Politik und machen damit einen ausgezeichneten Job.Wenn du Teil dieser Mission sein möchtest, schau auf https://engineeringkiosk.dev/handelsblatt vorbei und werde ein Teil der HANDELSBLATT MEDIA GROUP.********Das schnelle Feedback zur Episode:

"...Happy birthday dear ThursdAIiiiiiiii, happy birthday to youuuuuu

 If we understand Mozart then we can get a broader understanding of the divine. And we skip the morality about sexuality and profanity. Mozart was such rascal and genius to the same time.Mozart was obsessed with sex and cracked, dirty, profane jokes, without even thinking of the consequences of his bad behavior…Even he did openly sex in public toilets… There is no ending of his misconducts...  With 4 years he started to compose, with 7 years he had composed already a complete concert…Mozart composed also dirty songs, for instance: Leck mir den Arsch Fein recht schön saber. (I refuse to translate)Can you do such thing?And he never had corrected any note that he composed.Mozart could write entire concerts out of his mind, without correcting anything.Amadeus Mozart was a channel of the Lord…How does such thing work out…?If we are totally relaxed and open mind, only then the Lord can choose us as a channel.What I described in a previous blog, within an instance of a second, I got so deep insights and great solution when I was under the shower.I had designed the hardware for the satellite navigation system already and the software was missing and I was running out of time… Within 3/2 hours I wrote down the complete program in Assembler (microprocessor language) just so. For that task I would normally need 6 weeks… For sure, I had to correct this program, because I am not a genius… At this time, I had also an awesome sexual life, that made me so relaxed… I lived for 10 years in an Ashram and watched the absurdity of a perverse system…To create so many rules to live in chastity (abstinence…) a religious life…So, more rules so more the rules were broken, at the end who cared/cares in an ashram, monastery for rules? The Guru/Abbot looks that his disciples keep the rules and he/she is breaking the rules/morality by him/herself.Morality is for the others, never for yourself. (Oscar Wild)When I was attending a worship of God in an African church, then Jesus was coming.Did we chase purity? We were dancing and singing the praise of the Lord like crazy.The priest was yelling and even rolling on the ground when he broke out in anger…Such madness and divine…The church was filled with so much spirituality, that Jesus had to come.And that should happen in every church or temple.A religious system that is obsessed with absurd rules will never connect to the Lord/divine, even more it will prevent love and spirituality...And we can watch the religious fanaticism, that kills/killed so many people…For what are the Religions good for? My video: Can we understand God? https://youtu.be/uu_pFdsjhkQMy audio: https://divinesuccess.net/wp-content/uploads/2021/Podcast1/Can.we.understand.God.mp3

Trouver Sa Voie™ – La Nouvelle Méthode d'Intropection réaliste. Dans ce 23e épisode, je te condense les 6 étapes les plus pragmatiques pour trouver sa voie dans le contexte actuel. Je ne suis pas un idéaliste rêveur qui va te dire de suivre ta passion. Tristement, bien trop de qualités pros (et surtout humaines) sont broyées par ce système qui ne voit que le profit :

The Definition of Done This episode of The Modern .NET Show is supported, in part, by "The Definition of Done and Other Tall Tales". The Definition of Done and Other Tall Tales now available on Amazon. Get your hands on this literary masterpiece either as a beautiful physical book or conveniently for your kindle. Don't miss out on this unique intersection of tech and text. Show Notes Welcome to The Modern .NET Show! Formerly known as The .NET Core Podcast, we are the go-to podcast for all .NET developers worldwide and I am your host Jamie "GaProgMan" Taylor. In this episode, I spoke with Scott Hunter about the dynamic world of .NET, open-source, and a bunch of the related technologies that Microsoft have released. Things like DevContainers: "Yeah. So I would tell people that listen to this: please check out dev containers. I waited way too long to check them out. I knew they existed for a long time and just was too busy and never actually dug deep into it. And now that I have, it's a really cool feature" - Scott Hunter. Along the way, we touch on the fact that .NET is not just open-source but actively accepts contributions from the wider development community - something unheard of in the .NET Framework days. As an example, .NET Seven had over 1,000 contributions from the developer community - not counting the changes that Microsoft's engineers made to it. We also touch on some advice that Scott has for participating in open-source communities, along with some hints as to how Microsoft helps to lead the community around their open-source projects. There's some great advice here, from someone who works in enterprise-lead open-source everyday. Supporting the Show If you find this episode useful in any way, please consider supporting the show by either leaving a review (check our review page for ways to do that), sharing the episode with a friend or colleague, buying the host a coffee, or considering becoming a Patron of the show. Full Show Notes The full show notes, including links to some of the things we discussed and a full transcription of this episode, can be found at: https://dotnetcore.show/season-6/navigating-the-netverse-from-assembler-to-open-source-marvel-with-scott-hunter/ Useful Links Wildcat dot.net Azure Developer CLI aka "azd" Dapr Code Spaces dev containers nvm .NET reliable web app pattern Fedora Silverblue .NET Blog The Modern .NET Show Code of Conduct HomeBridge Shared Source Initiative JSON.net JSON.net on NuGet.org Episode 72 - Emulating a Video Game System in .NET with Ryujinx Microsoft Graph Performance Improvements in .NET 8 Graal Supporting the show: Leave a rating or review Buy the show a coffee Become a patron Getting in touch: via the contact page joining the Discord Music created by Mono Memory Music, licensed to RJJ Software for use in The Modern .NET Show Remember to rate and review the show on Apple Podcasts, Podchaser, or wherever you find your podcasts, this will help the show's audience grow. Or you can just share the show with a friend. And don't forget to reach out via our Contact page. We're very interested in your opinion of the show, so please get in touch. You can support the show by making a monthly donation on the show's Patreon page at: https://www.patreon.com/TheDotNetCorePodcast.

Quelle chance extraordinaire d'avoir une enfance banale où nous avons pu grandir en toute sécurité au sein d'une famille aimante! Malheureusement, beaucoup d'enfants n'ont pas pu avoir droit à ce même privilège. Non seulement ils subissent des manques, mais ils doivent composer avec la violence et les abus de toute sorte. Pour survivre à des traumatismes profonds vécus très tôt dans leur vie, ces enfants développent de puissants mécanismes de défense. Même si les menaces elles-mêmes en viennent à disparaître, ces mécanismes, eux, vont demeurer. Ces mécanismes prennent différentes formes et engendrent une variété de conséquences dans la vie d'adulte. Il demeure très difficile de déconstruire par la suite ce qui a pu être aidant à notre survie. Voilà l'origine des troubles de personnalité selon Jacques Debigaré, professeur en psychologie à l'Université de Trois-Rivières. Dans cet épisode, j'aborde son ouvrage de référence qui s'avère extrêmement riche en informations concernant les 10 troubles de personnalité du DSM. Nous allons explorer ensemble l'origine des troubles au moment de l'enfance ainsi que les pistes d'intervention en psychothérapie afin de réassembler les morceaux de ces enfances brisées. Ordre du jour 0m23: Introduction 13m24: Présentation du livre 17m10: Explication générale sur les troubles 23m15: Différentes approches thérapeutiques 35m46: Introduction aux 10 troubles 49m30: Schizoïde 53m21: Schizotypique 57m13: Dépendant 1h02m44: Évitant (en lien aussi avec la personnalité passive-agressive) 1h05m38: Obsessionnel (en lien aussi avec la personnalité type A) 1h09m02: Paranoïaque 1h12m36: Personnalité limite (Borderline) 1h17m13: Antisocial 1h22m51: Histrionique 1h28m15: Narcissique  1h32m26: Réflexion personnelle Pour encore plus de détails, consulte la page web de l'épisode

Un nuevo 808 en el que descubrimos las últimas creaciones de Fort Romeau, Dusky o Karen Juhl entre muchas otras. Ponemos en marcha el Generador de Ideas para entender por qué es necesaria la despolitización del cambio climático y Criminal Crisis está presentando proyecto. La Lista I: apaull - Tight Dope (Dina Summer Remix) [Furnace Room Records] Nightmares On Wax - Whodunit [WARP] Eartheater - Crushing [Chemical X] Anagrams - Birds on Clifton [Balmat] Altinbas - Radiance [Observer Station] Al Habla: Criminal Crisis. La Lista II: frankydrama - Everybody Dance! [Criminal Crisiis] Rupert Clervaux & Dania III [OOH-sounds] Fort Romeau - Blue [Romantic Gestures] EMJIE - Owner of a Lovely Heart [True Romance] Sega Bodega & Safety trance - Arena! Nutritious - I Love Mitsubishis [Paper Recordings] Guy Gerber - Rainchecks In Montreal (Roy Rosenfeld Remix) [RUMORS] La Lista III: Blake Reyes - The Dreamer [Axis Records] Lupe - The Invocation (Alinka Remix) [Pets] Jasper Tygner x DJ BORING - So Unknown Karen Juhl - Whole World In My Hands [inklingroom] Dusky - Free Your Mind [17 Steps] Seb Wildblood - 366 (ft. laraaji) [All My Thoughts] Generador de Ideas: Por la despolitización del cambio climático, con Emilio Chuvieco. La Lista IV: Luke Hess - E. Grand Blvd. [TS series] Dave NA - Planet Eli [Typeless] Casual Treatment - Miles Away [EarToGround] Mundo D - Outta Space [Espacio Cielo] Phil Berg - Sinara [SK_eleven] Assembler code & Jensen Interceptor - Not a Test Powel - First Swim Of The Year [Seven Villas Music]

Delphine est cheffe d'atelier pour l'assemblage des airbus A320 et elle vous explique tout ce qu'il faut savoir sur son métier.  ⬇️ Plus d'informations ici ⬇️ TIME CODES ⏱️ 00:00 Introduction 00:14 Présentation de Delphine et de son métier 00:41 Comment passe-t-on de la biochimie au montage des avions 00:58 Comment changer de métier en 3 mois ? 02:15 A quoi ressemble le quotidien? 02:57 Construire des avions quand on est une femme  03:37 Un métier répétitif? 04:31 Les plus grosses difficultés rencontrées pendant la formation et au quotidien? 06:28 Comment faire ses preuves dans un métier masculin quand on est une femme?    08:29 Pourquoi y a-t-il seulement 17% de femmes en atelier?  09:25 Quel est l'intérêt pour les entreprises d'embaucher des femmes?  10:32 Vaut-il mieux travailler avec des hommes ou avec des femmes?  11:34 Comment choisir un métier qui nous plaît?  13:25 Les conseils de Delphine pour se lancer dans l'aéronautique _____________________________ Interview à retrouver en version vidéo ici

Dave Cole remembers his first encounter with the TSO TEST command, back during the mid-1970s. “I said to myself, I can do better,” he recalls, concluding, “I did better.” Four decades later, ColeSoft z/XDC is the benchmark of assembler tools, relied on by IBM Z developers worldwide for analyzing code. z/XDC continues to evolve -- and it's helping train the next generation of IBM Z talent. “It's exciting to get younger people coming around,” Dave says. “We can generate some real excitement once we get somebody who's committed to that direction.” Listen and hear where z/XDC is headed next … Antarctica, perhaps?To learn more about ColeSoft and z/XDC, visit their website.  Join the ISV Ecosystem User Group on the IBM Z and LinuxONE Community for more  updates on how ISVs and partners are innovating the IBM Z platform: blogs, events, videos, discussions, and more.  Join here.And don't forget IBM Z Day, coming on October 18. Join this one-say online event to learn the very latest about innovation from IBM Z, spanning AI, hybrid cloud, quantum-safe security, and more. Register here.Subscribe to z/Action! Each month we meet some of the world's most innovative companies as they share how they're expanding horizons and driving success with IBM Z.

Ingrédients pour 6 personnes : 600 g de blancs de poulet coupés en cubes 100 g de chorizo (doux ou fort selon vos goûts), coupé en fines rondelles sel, poivre selon vos goûts brochettes en bois Pour la sauce légumes : 1 oignon 1 gousse d'ail, (ou + si vous aimez) 15 g d'huile d'olive 3 tomates mûres 1 poivron rouge ou jaune 1 pincée de sucre en poudre 1 gobelet d'eau 50 g de chorizo doux ou fort coupé en fines rondelles 1 grosse càs de crème fraiche épaisse, ou 50g de feta sel, poivre selon vos goûts   Préparation : Hacher l'ail et l'oignon finement et faites-les revenir dans l'huile d'olive pendant 5mn. Ajouter les tomates coupées en 2 et le poivron en morceaux, assaisonner (sucre, sel, poivre), ajouter 100g d'eau. Assembler sur... • La suite sur https://www.radiomelodie.com/podcasts/11325-poulet-chorizo.html

What the kingdom of God looks like; Loving God; Existence of Moses; Ecclesiastes; Sacrifice of fools; Taking oaths; Pagan gods; Clinging to delusions; Vanity; Corban of the Pharisees; Shepherds; Getting out of the world systems; Well-read apostles; Idiotes; Bearing witness; Being diligent; Mt 22:17-21; Gurus?; Ecclesiastes 6:1; Charity; Snares and traps; Living in darkness; Prov 1:10; Identifying the spirit of God; Nimrod; Increasing vanity; Having life more abundant; Your need for repentance; Seeing your part in trauma; Networking; Legal charity; Your goal; Hearing the cries of others; Law of nature; Right to choose; Sparing "the rod"; Minister's job; Free assemblies; Seeking the Holy Spirit; Q and A; Knowing who you are?; Saving yourself?; Witness testimony; Being hurt by Gregory's teachings?; Value of fiat money?; Notes; Redeemability; Bank loans; Defrauding bankers; Being friends with the unrighteous mammon; Going back into bondage; Avoiding the light; Mark of the beast; Seeking the Kingdom; Learning to help one another; Pretend salvation; Coming together; Q: Unrighteous Mammon?; Following the still-small voice; Meditation; "I don't know" prayer; Knowing yourself; Waiting upon the Lord; Gregory history; Bible about law and government; Kingdom in the moment; Seeking the kingdom so nobody has to take the world's benefits; His Holy Church; Early Church; "Other" witnesses; Christian checklist; Follow God's leading; Congregating; Serpent lies; "Assembler"; Voluntary society; Not-so-early Church; Fasting and prayer; Declining empires; Instructions for Christ's ministers; Seven men throughout the kingdom; "Tables"; Credit unions; Crossing the Red Sea; "Rhomaios"; Fitting the puzzle; Acts 19; Tax burdens for shipping; Trust; Fractional reserve banking; Non-participators; Invest in one another; 1 Cor 12:13; 'Why the Network"; Mt 5:46; First fruits; Joining the journey; Lk 6:32; 1 Cor 1:12; Don't be a foolish virgin.

Today, we meet with Mark Wallace. Mark wrote his first computer program in 1965, and has written a lot of them since, using languages ranging from Assembler to SQL. His interest in zero defect software led him to study software engineering methods such as Structured Design and Object-Oriented Design, and ways to adopt them using Computer-Aided Software Engineering (CASE) tools. In recent years, he has taught robotics to middle and high school students, and served as a judge in the World Robot Olympics and First Lego League competitions. He is now retired in Boynton Beach, but volunteers to teach computer programming to high school students through a Microsoft-sponsored charity. We met Mark recently while we were all judging student robot presentations and we were quite impressed. We know you will be too and we hope you stay tuned after for the takeaway. Link for the Microsoft program mentioned in the podcast: https://www.microsoft.com/en-us/teals/about --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app Support this podcast: https://anchor.fm/shawna-christenson2/support

Array Cast - February 17, 2023 Show NotesThanks to Bob Therriault and Adám Brudzewsky for gathering these links:[01] 00:01:20 APLSeeds '23 https://www.dyalog.com/apl-seeds-user-meetings/aplseeds23.htm[02] 00:02:26 KXCon https://kx.com/events/kx-con-2023/[03] 00:04:30 plrank.com https://plrank.com/[04] 00:05:30 Michael Higginson ArrayCast Episode https://www.arraycast.com/episodes/episode46-michael-higginson Iverson Centenary https://britishaplassociation.org/iverson-centenary-december-2020/[05] 00:06:30 Lower Canada College https://www.lcc.ca/ IBM 2741 https://en.wikipedia.org/wiki/IBM_2741 Anderson Jacobson serial modem https://en.wikipedia.org/wiki/Anderson_Jacobson Gilman and Rose - An Interactive Approach https://apl.wiki/Books#APL_―_An_Interactive_Approach Leap Year https://en.wikipedia.org/wiki/Gregorian_calendar#Accuracy APL implementation Leap Year https://tryapl.org/?clear&q=≠%E2%8C%BF0%3D4000%20400%20100%204∘.%7C1600%201700%201800%201900%202000%202100%202200%202300%204000&run[06] 00:13:53 Larry Breed https://apl.wiki/Larry_Breed Scientific Time Sharing Corporation https://en.wikipedia.org/wiki/Scientific_Time_Sharing_Corporation STSC promotional video https://www.youtube.com/watch?v=mjgkhK-nXmk 666 BOX https://www.jsoftware.com/papers/APLQA.htm#666box[07] 00:17:20 University of Toronto https://www.utoronto.ca/ Arthur Whitney https://aplwiki.com/wiki/Arthur_Whitney I.P. Sharp and Associates https://apl.wiki/I.P._Sharp_Associates[08] 00:18:23 360 Assembler https://en.wikipedia.org/wiki/IBM_System/360_architecture#Instruction_formats Eric Iverson https://aplwiki.com/wiki/Eric_Iverson[09] 00:22:40 IESO https://www.ieso.ca/[10] 00:22:50 Smart Meters https://en.wikipedia.org/wiki/Smart_meter[11] 00:23:30 Kdb+ https://code.kx.com/q/learn/brief-introduction/[12] 00:24:30 First Derivatives https://fdtechnologies.com/ KX https://kx.com/ KX Sensors https://kx.com/solutions/energy-utilities/[13] 00:27:52 George Hotz https://en.wikipedia.org/wiki/George_Hotz[14] 00:36:56 ⎕ec https://abrudz.github.io/SAX2/SAX61.pdf#page=790[15] 00:41:20 APL Programming Language https://en.wikipedia.org/wiki/APL_(programming_language) Blackberry RIM https://en.wikipedia.org/wiki/BlackBerry_Limited Rise and Fall of Blackberry https://www.businessinsider.com/blackberry-smartphone-rise-fall-mobile-failure-innovate-2019-11[16] 00:45:45 Ken Iverson https://en.wikipedia.org/wiki/Kenneth_E._Iverson Guy Steele https://en.wikipedia.org/wiki/Guy_L._Steele_Jr.[17] 00:55:12 Nick Psaris ArrayCast Episode https://www.arraycast.com/episodes/episode42-nick-psaris-q[18] 00:56:23 Right Parenthesis ) https://apl.wiki/System_command Quad ⎕ https://apl.wiki/Quad_name[19] 00:57:16 APL2 https://aplwiki.com/wiki/APL2 Axiom System https://dl.acm.org/doi/pdf/10.1145/800136.804446 Trenchard More https://en.wikipedia.org/wiki/Trenchard_More Jim Brown https://aplwiki.com/wiki/Jim_Brown[20] 00:59:28 SHARP APL https://aplwiki.com/wiki/SHARP_APL Roger Moore https://en.wikipedia.org/wiki/Roger_Moore_(computer_scientist) Richard Lathwell https://en.wikipedia.org/wiki/Richard_H._Lathwell[21] 01:04:15 Array Models https://apl.wiki/Array_model[22] 01:04:50 Strand Notation https://apl.wiki/Strand_notation[23] 01:06:05 J Programming Language https://www.jsoftware.com/indexno.html[24] 01:18:02 q Programming Language https://kx.com/academy/ Type of https://apl.wiki/Type[25] 01:21:13 Haskell Programming Language https://www.haskell.org/[26] 01:24:30 ⎕ML Migration Level https://apl.wiki/Migration_level[27] 01:25:50 Oxide and Friends https://oxide.computer/podcasts/oxide-and-friends Java Pubhouse https://www.javapubhouse.com/episodes[28] 01:27:26 British APL Meetings https://britishaplassociation.org/[29] 01:35:06 contact AT ArrayCast DOT COM

Floppy 45 – Astro Assembler con Mac y Rhino de Batman Group. Si te gusta nuestro contenido recuerda apoyarnos con una recomendación o echando una mano con los gastos del server

resent (v.) c. 1600, "feel pain or distress" (a sense now obsolete); 1620s, "take (something) ill, consider as an injury or affront; be in some degree angry or provoked at," from French ressentir "feel pain, regret," from Old French resentir "feel again, feel in turn" (13c.) sentient (adj.) 1630s, "capable of feeling, having the power of or characterized by the exercise of sense-perception," from Latin sentientem (nominative sentiens) "feeling," present participle of sentire "to feel" 1. Sentience: the capacity to feel, perceive, or experience subjectively. 2. Sentiency: the state of being aware of one's surroundings and of having a conscious experience. 3. Sentimentalism: the tendency to rely too heavily on emotions when making decisions or forming opinions. 4. Sentimentality: the excessive display of emotion, especially in an overly sentimental manner. 5. Sentiment: a general feeling or opinion about something, based on emotion rather than reason. 6. Sentimentalize: to make something overly sentimental or to cause something to be viewed sentimentally. 7. Sentimentality: an excessive or mawkish display of emotion. 8. Sentimentalize: to cause something to become overly sentimental. 9. Sentimentalism: an excessive attachment to or reliance on emotion. 10. Sensibility: the capacity to perceive or feel things. resemble (v.) "be like, have likeness or similarity to," mid-14c., from Old French resembler "be like" (12c., Modern French ressemble), from re-, here perhaps an intensive prefix, + sembler "to appear, to seem, be like," from Latin simulare "to make like, imitate, copy, represent," from stem of similis "like, resembling, of the same kind" 1. Semblance - a superficial resemblance or outward appearance 2. Assembler - one who assembles or puts together reservation (n.) late 14c., "act of reserving or keeping back," from Old French reservation (14c.) and directly from Late Latin reservationem (nominative reservatio), noun of action from past-participle stem of Latin reservare "keep back, save up; retain, preserve," from re- "back" + servare "to keep, save, preserve, protect" 1. Servile - adj. excessively submissive; slavish 2. Service - n. an act of helpful activity; assistance 3. Servitude - n. the state of being a slave; forced labor 4. Serve - v. to be of use; to be of service 5. Servitor - n. a servant; one who is subservient 6. Servitude - n. the condition of being a slave; forced labor 7. Servitorial - adj. of or relating to a servitude; subjugated 8. Servilely - adv. in a slavish manner; submissively 9. Servitorially - adv. in a servitorial manner; submissively --- Support this podcast: https://anchor.fm/liam-connerly/support

The first 48 hours of “8-Bit Week” here at The Lunduke Journal has been an absolute blast!Apple II. Commodore 64. Tandy Color Computer 3. Atari 800. These first two days of 8-Bit Week were filled to the brim with fun, fascinating posts by members of The Lunduke Journal Community.Below is a, roughly chronological, list of 8-Bit Week posts in our community. Read through them all… or simply check out the ones that interest you. There's something here for everyone. (Then scroll to the end of this post for a short selection of some of the fun pictures and screenshots posted so far. So much fun stuff in there.)ii6* 8-Bit Week kickoff podcast!* An 8-Bit breadboard, DIY computer kit* Darius, an 8 bit shooter* An 8 bit bug* 6502 programming this week!* Commodore 64 on The Computer Chronicles* Big stack of Atari 2600 games!* Reminiscing about C64 days* Apple IIe restoration project* C64 emulation via VICE on Linux* Commodore 64 ads from the 1980s* Keymap for VICE* Disassembled Apple IIe* Running GEOS on actual C64 hardware* Assembler programming on an 8 Bit Atari* The 10 Best Commodore 64 games… ever* A much cleaner Apple IIe! So purdy!* Playing Ballblazer on the Atari 800* Are you keeping up with Commodore?* Doing word processing on a Vic 20* “Hello World!” in assembly on an Atari 800* BASIC computer games book!* Web based emulators* More BASIC computer games books!* Fixing the start button on a Gameboy Color* Vic 20 syntax errors! Huzzah!* AND and OR!* Turbo Rascal : Pascal Compiler & IDE for tons of classic systems* Reading and writing files, in code, on multiple 8 bit systems* Computer Chronicles - Apple II Forever* Keycaps back on the restored and cleaned Apple IIe* Removing rust from the metal in 8 bit computers* Coding to make 8 bit computers useful today* Tandy Color Computer 3 emulator!* Bruce Lee on Atari 800 is brutal* 8 bit text adventure by one of our own!* Using a laptop touchpad as an emulated KoalaPad on an emulated Atari* Apple IIe restored! … Now what?* “Duplicate this Diskette!”* VICE working great on BSD… not on Linux! Grrrr* Using a C compiler on an Atari 130XEAnd, behold, a sampling of photos and screenshots from the first two days of 8-Bit Week! This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit lunduke.substack.com/subscribe

In this episode, Jutta Eckstein, an independent coach, consultant and trainer, based in Germany, shares Her origin story of starting as a product engineer, with an interest in software developmentStarted as a trained teacher and when the need for teachers dropped, went on to study product engineering and studying Pascal - and completely falling in love with software developmentAlso getting trained as pollution control commissioner, when she could move from street protests to actually working to keep pollution under controlHer early experience with Pascal and Assembler, and Smalltalk being her all time favoriteBeing part of the professional communities such as OOPSLA, and getting an orientation on the techniques and practices that got crystallized as Agile practicesHer transition from an engineer to a coach : discovering her strength based on a trigger by her project managerMoving into areas of architecture and design and becoming a team coachThe difference between a consultant and coach rolesStudying business coaching and change management, to get a formal understanding and foundationHow that enabled developing connections with people across various industriesMy task is not to create the right mindset, my task is coming with the right mindset myselfThe importance of listening, coming with experience, and working with expertsStarting with a retrospectiveStarting with a few questions: clients having prior experience with changeWhy do you think it will be successful this timeWhat hinders you from starting nowIf she discovered anything surprising in these initial explorations… her response of a pattern she sees.. In the next episodeJutta Eckstein works as an independent coach, consultant, and trainer. She has helped many teams and organizations worldwide to make an Agile transition. She has a unique experience in applying Agile processes within medium-sized to large distributed mission-critical projects. Jutta has recently pair-written with John Buck a book entitled Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy (dubbed BOSSA nova). Besides that, she has published her experience in her books Agile Software Development in the Large, Agile Software Development with Distributed Teams, Retrospectives for Organizational Change, and together with Johanna Rothman Diving for Hidden Treasures: Uncovering the Cost of Delay in your Project Portfolio.Jutta is a member of the Agile Alliance (having served the board of directors from 2003-2007) and a member of the program committee of many different American, Asian, and European conferences, where she has also presented her work. She holds a M.A. in Business Coaching & Change Management, a Dipl.Eng. (MSc.) in Product-Engineering, a B.A. in Education, and is trained as pollution control commissioner on ecological environmentalism.links: @JuttaEckstein | https://www.linkedin.com/in/juttaeckstein/ | https://www.jeckstein.com/| https://www.agilebossanova.org | https://jeckstein.com/sustainability

In this episode, I had the pleasure of talking with Doug Bierer about his history in computing, a history which if you're a computing hardware or programming nerd, you're going to love. Doug shares how he got in to computing with the TRS-80 and Commodore 64. How he taught himself to program in Assembler during shifts when he had some quiet time, and how music was what lead him to programming. We both recount our time in computing back in the 90's and what it was like to work with Microsoft Windows and UNIX/Linux.Some key takeaways are: Throwing hardware at the problem doesn't fix it. Bad code upon bad code just makes more bad code. Automating code creation doesn't necessarily result in good code. Less is more. A GiveawayFor a chance to win a copy of Doug's new Book, PHP 8 Programming Tips, Tricks, and Best Practices, leave your thoughts, your feedback on the episode. Doug and I will give one copy of the book to the person that, in our opinion, leaves the most interesting feedback. You can comment at https://www.freethegeek.fm/48, or on Twitter. Make sure you tag the show (@freeingthegeek).Links PHP 8 Programming Tips, Tricks, and Best Practices (Doug's NEW Book) Unlikely Source (Doug's Company) The TRS-80 The Commodore 64 DR DOS The Motorola 6809 Peek and Poke Unixware Novell U.S. Antitrust law GitHub Copilot Potsdam State University of New York Guests: Doug Bierer (@bierer_doug).Hosted By: Matthew Setter.Thanks for tuning in to Free the Geek. If you'd like to be a guest on the podcast or know someone who'd make a great guest, email me: matthew[at]matthewsetter.com. This podcast is produced by Matthew Setter for the Web Dev With Matt "network".SupportIf you want to support the show, you can always buy me a coffee. I'd greatly appreciate your financial support. ★ Support this podcast ★

Es ist 2022 und Job-Interviews werden immer noch geführt wie vor 100 Jahren. Nur das Gejammer über Fachkräftemangel wird jeden Tag lauter! Reden wir doch mal über typische Fehler, die Bewerber vertreiben, und zwar weit, weit weg und auf Nimmerwiedersehen...! Willkommen bei Human Resources (nein, die Realität, nicht Netflix!)Ich hatte euch schon mal von meinem schlimmsten telefonischen Interview berichtet. Damals war die Marktlage eine andere. Heute ist es wieder ein Bewerbermarkt. Sprich: die Firmen legen sich ins Zeug, um den Bewerber für das Unternehmen zu begeistern. Und trotzdem platzen viele Gespräche und führen am Ende nicht zu einem Arbeitsvertrag und einem neuen Mitarbeiter. Und in den meisten Fällen, weil ein einziger interner Bereich immer noch im Mittelalter hängt und es leider eben auch viel zu viele schlechte Personaler gibt! Kurze Frage, bevor wir an die wahren Gründe gehen, warum HR in vielen Unternehmen einfach abgeschafft werden kann und es danach und ohne diesen Bereich einfach nur besser werden kann: Eine Bewerbungsunterlage besteht aus Anschreiben, Lebenslauf, eventuell einem Motivationsschreiben und den Anlagen, also Zeugnisse, Zertifikate und all das wichtige Zeugs. Was glaubt ihr, wie lange sich der durchschnittliche Personaler in der Vergangenheit, also bevor der Markt zugunsten der Bewerber sich drehte, für die Erstdurchsicht einer Bewerbung Zeit genommen hat? 15 Minuten? Eine Stunde? Einen halben Tag? Ich löse mal kurz: Im Durchschnitt werden nur das Anschreiben und der Lebenslauf zu einem "Kennenlernen" herangezogen. Die Zeit dafür liegt zwischen 30 Sekunden und maximal drei Minuten. BITTE? Ja, ihr habt richtig gehört! Der Bewerber sitzt zu Hause, findet die ideale Stelle für seine Ausbildung. Passend auch die Fortbildungen. Und auch die letzten Jahre Profession genau in dem Bereich, der hier gesucht wird. Also ein Anschreiben, dass auf maximal eineinhalb Seiten darlegt, warum man der richtige ist. Erfolgreiche Umsetzung ähnlicher Tätigkeiten schildern. Und schon steigt die Vorfreude auf ein Interview. Und jetzt sage ich euch: Schlechte Personaler lesen Anschreiben gar nicht, der Rest benötigt keine 15 Sekunden, um zu glauben, dass er euch auf Basis des bisschen durch gerasterten schon durch und durch kennt. Zack, Schublade auf, Pech gehabt, lieber Bewerber! Verdauen wir Tiefschlag eins, es geht ja noch weiter. Kommen wir zum Lebenslauf: Wie lange prüft ein durchschnittlicher Personaler deinen Lebenslauf? Also, ein Personaler der Art, der bis heute nicht verstanden hat, was das Unternehmen so genau eigentlich macht. Und der auch von den eigentlich ausschreibenden Bereichen in der Firma nur als teure und intern quersubventionierte Last gesehen wird. Und der ja bestenfalls nur abgleicht, ob dein Vorwissen oder deine Ausbildung zu der Ausschreibung passt. Und der sich Zeit nehmen sollte, zu lesen, was du eigentlich schon so gemacht hast. Und warum tut immer jeder so, als gäbe es ganz wichtige Positionen am Ende des Lebenslaufs, wie Hobbys, wenn das sowieso alles übersprungen wird, weil noch ganze drei andere Bewerbungsmappen für den Job auf dem Schreibtisch liegen? Zurück zur Frage: Wie lange sichtet ein Personaler deinen Lebenslauf? Möge Maren Gilzer bitte die erste Schätzung umdrehen... NEIN, GANZ FALSCH! Wir liegen hier zwischen 45 Sekunden(!) und keinen fünf Minuten. Das würde ich gerne mal mit Janina Kugel im Interview diskutieren! Wieso komme ich jetzt nur nach diesen einleitenden Fakten auf die tagtägliche Praxis? Ach ja, genau. Weil es Zeit wird, mal zu diskutieren, wie die durchschnittliche und nicht unbedingt gute HR so arbeitet, egal, ob als Bereich, als Cost Center oder einfach nur auf dem Flur, der sonst leer stehen würde. Die seit Jahren geforderte Stabsstelle, die unabhängig auch noch bei der Geschäftsführung aufgehängt sein sollte? Bei den vielen schlechten Personalern, die ich so kenne, und auch den diversen, die tatsächlich zumindest den Weg in die obersten Weihen der Firmen geschafft haben, kann ich nur sagen: nein - lieber ganz weg damit! Es ist 2022, der Bewerber hat aktuell alle Vorteile auf der Hand, also wie müsste eine gute Human Relations, die gegenderte Titulierung unter den hilflosen Human Ressources, also aussehen? Ehrlich, realistisch und offen. Schafft als Erstes das Anschreiben ab, wenn es für euch nur Altpapier ist. Aber nein, ihr seid alle verkappte und verkante Genies im HR, wer ein Anschreiben in 15 Sekunden durchdringt, benötigt für "Die Zeit", ja, die Zeitung, auch keine 10 Minuten. Aber was von beiden wirklich hängenbleibt, ohne auf zu kurzen Synapsenwegen vergessen oder nach persönlichen Vorlieben oder Prägungen komplett fehlerhaft hineininterpretiert wurde, lassen wir mal. Vielleicht sollten viele HR-Abteilungen wirklich "Die Zeit" abonnieren. Als Zweites, und das baut direkt auf den ersten Punkt auf, legt eure künstliche Arroganz der Unfehlbarkeit und die damit verbundene Unnahbarkeit ab. Ich habe schon HR-ler erlebt, die auf der untersten Sprosse standen und dem Firmenchef gleich mal schlaue Texte drücken mussten, auch im Hinblick auf seine Rolle im Unternehmen... nicht wirklich clever. Aber am schlimmsten sind hier die eigentlichen Wunschkandidaten in HR, die Super-Psychologen und schlimmere Konsorten. Liebe HR, ihr wollt wissen, warum ihr bei Ausschreibungen immer so spät oder nur noch zum Rechtschreibfehler korrigieren hinzugezogen werdet? Hmmm... ratet mal...! Und drittens: Aktuell ist ein Bewerbermarkt. Wie lange warte ich als Bewerber, der drei Bewerbungen rausgeschickt hat, auf eine Rückmeldung? Drei Tage? Eine Woche? Oder irgendwo dazwischen? Und glaubt mir, nicht jede Bewerbung, die ihr bekommt - aber was sage ich, das habt ihr nach sieben Sekunden ja schon rausgelesen! - ist eine auf eine Wunschfirma. Also: Bewerbungen kommen per E-Mail, somit hat bei Eingang bis Mittag nachmittags eine Antwort rauszugehen, sonst am nächsten Tag vormittags eine Rückmeldung von euch zu erfolgen. Und nicht dieses "blabla Eingang bestätigen wir blabla melden uns unaufgefordert innerhalb der nächsten Dings Wochen blabla!". Sonst könnte es sein, dass der Mitbewerber fünf Minuten schneller war und der Kandidat vielleicht nicht mal mehr euren Anruf annimmt. Apropos: was sind das eigentlich für Stellenausschreibungen, die ihr manchmal allen Ernstes inseriert? "Sie sind ein wichtiger Bestandteil des Unternehmens und prüfen in Abstimmung mit unserer kompetenten Fachabteilung im Rahmen des Produktproduktionsprozesses die Fähigkeiten und Verbesserungspotentiale für unsere regionalen und überregionalen als auch weltweiten Kunden." Ist das nun ein Dixie-Klo-Tester oder ein 500.000 €/Jahr-Job in der Halbleiterindustrie? Oder hat das Apple so ausgeschrieben? Und lasst bitte diese wunderbaren Worte, die ihr beim letzten überregionalen HR-Stammtisch von den "Großen" aufgeschnappt habt, weg, wenn euch nicht bekannt ist, was agil bedeutet. Oder Projektmanagement. Und was spricht, wenn es schon eine Absage werden soll, gegen ein paar warme Worte? Ein bisschen Mitgefühl, dass es heute auf diese Stelle nicht geklappt hat, man sich aber schon über die nächste Bewerbung freut? Statt diesem Rechtsabteilungsblödsinnformulierungen a'la "müssen wir Ihnen mitteilen, dass wir uns anderweitig für einen Kandidaten entschieden haben". Kotz, Würg, Kraus! Klar haben wir Gesetze, die bei falschen Formulierungen schnell auch einen wirklich schlechten Kandidaten auf diese Position bringen würde. Aber nein, der trickst sich lieber mit Anwalt und einer Summe von 300 bis 750 Euro bei zehn Firmen durch, weil er damit auch wieder ein halbes Jahr leben kann, bevor er erneut Bewerbungen schreiben muss. Also... habt ihr ne Idee, was da stehen könnte und den Bewerber nicht gleich veranlasst, euch auf seine Rote Liste zu setzen, für die Zukunft? Ich war vor kurzem in einer virtuellen Runde zu Gast, wo sich die Personaler wieder so wirklich gegenseitig an die Schultern gelehnt und sich über die bösen, jetzt im Vorteil befindlichen Bewerber ausgekotzt haben. Was die alles wollen. Wie schnell die angeblich schon wieder einen neuen Job haben. Dass sie nur zu namhaften Firmen wollen, die ländliche Region ist ihnen völlig egal. Und dass viele sich auf Schreiben, egal ob E-Mail oder Post - nein, man schreibt heute nicht mehr per Post bei Antworten auf Bewerbungen! - gar nicht mehr zurückmelden oder telefonisch nicht mehr greifbar sind. Ja, das ist ein Phänomen aus der Dating-Branche, das manch einer auch besser auf seine Exfrau, bevor sie diesen Titel abgreifen konnte, anwenden hätte sollen: einfach nicht mehr zurückmelden. Ghosting. Unsichtbar werden und bleiben, egal, wie viele Anrufe, E-Mails, Anfragen, Bettelmailboxnachrichten und verzweifelte Rückrufangebote auflaufen. Seht es ein: nach all eurer umfangreichen Arbeit, in unter 15 Minuten DEN zukünftigen Mitarbeiter gefunden zu haben, und nun geht er nicht ans Telefon und reagiert auf keine Mails? Leute, der hat einfach was Besseres gefunden und jetzt keinen Bock auf blöde Diskussionen mit schlechten Personalern! Daher: "Die gewählte Nummer ist leider nicht vergeben, bitte rufen Sie die Auskunft an!". Und, bitte, bitte, bitte, passt auf, wenn das Schlagwort "KI" euch goldene Bewerberwiesen mit Milch, Honig und ganz wenig Arbeit verspricht. Zum Beispiel in Form von Stimmanalyse bei Erstkontaktanrufen. Oder die Vollpsychologenauswertung des Lebenslaufs. Macht mal einen Test: Googelt einen Serienmörder, idealerweise mit Berufserfahrung. bevor er das Metier gewechselt hat, und schmeißt die Daten in die KI - Glückwunsch zum neuen Mitarbeiter! Denkt man darüber nach - und testet es selbst, mir glaubt ja eh keiner! Und, ja, noch eine Spitzfindigkeit, die euch sonst intern eiskalt erwischen könnte: heißt es HR oder AIR? In vielen Fällen geben schlechte HRler nur ihre Verantwortung auf "Maschinen" ab, um somit bisherige schlechte Entscheidungen vom Tisch zu bekommen und ihr eigenes Unvermögen auch weiterhin unter den Teppich kehren zu können. Einen hab' ich noch, dazu habe ich auch schon einen kompletten Blog geschrieben: Bewertungsportale. Viele Firmen halten Bewerber, die alle mindestens ein technisches Start-up erfolgreich an SAP oder Microsoft verkauft haben müssen und die von Assembler bis Python alles aus dem Effeff programmieren können, für komplett bescheuert. Und den ganzen normalen Rest an Menschen auch. Wenn ein Bewerber eine Firma prüft - und das eben in mehr als fünf Minuten, liebe HRler! -, dann ist eine Suchmaschine ein guter Anfang. Und auch Bewertungsportale. Das persönliche Netzwerk, erschreckend, wer über wie viele Ecken jemand kennt, der da arbeitet oder gearbeitet hat und was der zu erzählen weiß! Aber noch viel dümmer sind Bewertungsportale. Wochenlang nicht eine einzige neue Bewertung und dann fallen zehn absolute fünf Sterne Ergebnisse innerhalb zwei Tagen ins Internet? Oder was ich in meinem Blog schon geschrieben habe: Eine Beurteilung über den Hergang eines ersten superduperscheißeistderLadengeil-Bewerbungsgesprächs als kleines Drohmittel für den weiteren Ablauf des Prozesses? Drauf geschissen, HR! Viel interessanter wäre es, wenn kununu und all die anderen Luftschlossverbreiter eine unabhängige Nachbewertung durch den ursprünglichen Autor erlauben. Zum Beispiel nach dem Zweitgespräch, sollte es, dank der tollen Online-Bewertung, überhaupt stattgefunden haben - und gerade auch bei einem plötzlichen Nein nach positiver Bewertung. DAS muss auf die Portale. Oder ob eine Bewertung von damals fünf Jahre später auch noch Bestand hat - oder ob man nun lieber ein anderes Unternehmen bewerten möchte... Kurz gesagt, mit all meiner Übertreibung, die ich schon im Web erleben durfte: monatelang nix im Netz und dann 50 (!) neue Topbewertungen an einem Tag, die sich alle aus einem unbekannten Grund fast gleich anhören? Ja, doch, genau da will ich arbeiten! Was aber machen, wenn in meiner Firma, wie eben in den meisten, eine schlechte HR-Abteilung ungebremst ihr Unwesen treiben darf? Ich wandle meinen Standardsatz dafür ein wenig ab: Mitarbeiter kommen wegen der Firma und gehen wegen schlechten Führungskräften und dank HR. Gute Leute werden aktuell überall gebraucht, also nicht zwangsweise in dem bisherigen Unternehmen. Und wenn du nun in einer schlechten HR-Abteilung gefangen bist? Gehen! Es ist Bewerbermarkt! Und, was ich auch schon gehört habe: Ich bin ein Mann im HR, ich finde woanders doch nix mehr. Quatsch! Keine Rücksicht auf Frauenquote, ich habe schon viele ausgezeichnete Kerle in der Personalabteilung erlebt, die die Arroganz so mancher Frau im Zehnerpack durch nur einen Satz "ausgespielt" haben. Schade nur, dass HR, wenn es darauf ankommt, den Schwanz einzieht. Beispiel gefällig? Wenn sich dem Firmenchef der Kamm aufstellt, und er unbedingt das Gespräch mit neuen hochrangigen Senior-Führungskräften führen will. Und HR nur als Gast ruhig und gelangweilt dabei sitzt. Noch prickelnder, wenn es dabei um einen neuen Chef von HR geht. Oder vielleicht sogar einen Vorstand, wobei das nur die Besten schaffen. Und besonders wichtig wäre der Einsatz von HR, wenn in so einem Vorstellungsgespräch die Wechselfrage kommt. Gefolgt von Aussagen über die letzten Jahre und die täglichen ICE-Fahrten - ja, jammer, jammer, mit BahnCard 100, 1. Klasse, auf Kosten des Arbeitgebers. Und dann noch die Aussage, dass das Problem die Familie ist, da diese eben hier den Wohnort hat und nicht am Platz der eigentlichen Arbeit und man so täglich 2x knapp 190 Kilometer zurücklegen muss - und das schon seit Jahren so handhabt. Da fällt mir gleich eine Gegenfrage ein: Schon mal was von Umzug gehört? Und schon beginnt das Spiel der unsinnigen Argumente seitens des Mitarbeiters - und so einen Quatsch soll ich mir dann täglich anhören, wenn man die dann einstellt - weil der CEO ungebremst mitmachen will? Und wieso muss nun auch jede nach Einstellung plötzlich einen X5 M konfigurieren, wenn sie plötzlich nur noch, statt eben 200 Kilometer einfach, keine 10 Kilometer mehr hat? Ich kann euch, auch in der aktuellen Zeit, nur empfehlen: seit Dienstleister im Unternehmen, aber im Hinblick auf eure Kunden. Das sind nicht die ausschreibenden Abteilungen, die benötigen euch nur, damit das interne Kauderwelsch allgemeinverständlich an den Mann gebracht werden kann. Eure Kunden sind im Bewerberprozess die Bewerber! Und die haben Wertschätzung und auch einen besseren Umgang als 45 Sekunden oder maximal 20 Minuten für ein "Profil" verdient - oder sie bekommen es eben bei jemand anderem oder schlimmstenfalls eurem Konkurrenten. Wenn euch das zu viel Arbeit ist, schaut doch mal, ob ihr nicht ein paar Ehemalige zurückgewinnen könnt. Oh, aktive Arbeit, E-Mail oder Handynummer finden... kleiner Tipp: Netzwerkportale oder schlimmstenfalls Facebook, anschreiben, abwarten, gute Arbeit machen! Und wenn, vielleicht sogar ohne Zutun eurer HR, sich partout keine Leute bei euch über extern gewinnen lassen - schult doch einfach, was da ist! Soll ja auch schon in manch anderen Firmen geklappt haben, sich die Kompetenzen und das Wissen einfach intern anschulen lassen und die Gehaltsstufen gleich mit befüllen. Oh, sorry, das war euch jetzt zu banal, ich verstehe. Und, wenn ihr es wirklich zum Nichtstun in einem Großkonzern geschafft habt, seid doch einfach die HR-Stelle, die am schnellsten und als Erster angefangen hat, in Nachbarabteilungen die Leute abzuwerben. Und die sich das Schreiben des panischen Abteilungsleiters oder Direktors mit stolzer Brust an die Wand hängen, dass ab sofort und als Weisung des Vorstands dieses Vorgehen nun zu unterlassen sei. Apropos: Weglaufen, wenn ein modernes Unternehmen noch Direktionsposten zu vergeben hat! Nach all meinen unqualifizierten, da ich mir einen richtigen Job und eben nicht HR gesucht habe, Äußerungen habt ihr in den jeweiligen HR vielleicht nun auch noch weitere Ideen, ganz egal, ob die auf meinen aufbauen oder von Google kommen. Oder von einem Fachartikel oder einem wirklich guten Personaler, nicht wahr, Frau Kugel? Und wenn nur einer ob meines Textes jetzt aufwacht und ein Einsehen hat und sich bessert, möchte ich nicht wissen, wie viele Neu-Einstellungen dann besser laufen. Auch wenn ich hier mit diesen, wenn auch sehr zynisch-übertriebenen und doch größtenteils der Wahrheit meiner beruflichen Laufbahn entsprechenden Erfahrungen und Schilderungen aufwarte. Und wie viele zufriedene Mitarbeiter damit auf die richtigen Positionen eingestellt werden. Glück auf! PodCast abonnieren: | direkt | iTunes | Spotify | Google | amazon | STOLZ PRODUZIERT UND AUFGENOMMEN MIT Ultraschall5 Folge direkt herunterladen

La Font Matrix, un concept simple et appliquable pour catégoriser et assembler des polices d'écriture... Source du concept : https://www.youtube.com/watch?v=731-k8xSyqE

@LeoPiccioli Cada éxito está compuesto por un montón de fracasos previos. Los medios no nos cuentan todas las veces que fracasaron los fundadores. Me gusta el fracaso porque es una señal de que lo intentaste. De chiquito me encantaba la computación. Programaba en BASIC y en Assembler, y también leía mucha ciencia ficción. En la UBA milité en política en TNT («Tontos pero No Tanto»), un partido en joda que fue creado para no ganar. Axel era excelente orador y, al menos por entonces, honesto. Él y yo nos graduamos el mismo día. Tengo foto con él, los dos «enhuevados». Está mal valuar a una empresa por sus ventas, pero lo hacemos todos. La valuación por ventas es cómoda porque suele usarse cuando la competencia cotiza en bolsa. En septiembre de 2016 me fui de Staples. Estuve 18 años en la misma compañía. Cuanto más tiempo estás en un laburo más difícil es irte. Lo que aprendí es que cada 3 o 4 años tenés que cambiar de laburo. No digo cambiar de empresa eh, sino de responsabilidades. LinkedIn es de las redes sociales más viejas que conocemos, es del 2004. Hasta que la compró Microsoft era buena, después se volvió mala. Ahora está volviendo a tener contenido de calidad. Tener una empresa tiene un desafío de decisiones que no me encanta. Por ejemplo: echar gente. En las empresas hay que poner la misión por encima de las personas. @LeoPiccioli dándole un consejo al Leo de hace 10 años: "Relajate, disfrutá del camino." https://twitter.com/ETPA_Spaces/status/1564011774994677761

SPÉCIAL NUTRITION

Jacques Bergeon talks guitar assembly, crazy stories from his youth, and a possible upcoming album??

Hoy hablamos de un interesantísimo proyecto de formación en programación creado por CRISTIAN FONDEVILA y KASIA ADAMOWICZ . Se llama ASSEMBLER INSTITUTE OF TECHNOLOGY y podéis encontrar toda su información a través del siguiente enlace: https://go.assemblerinstitute.com/keB En un mundo cada vez más tecnológico éste área es un campo con muchísimo futuro tanto por las posibilidades en el ámbito laboral como por las necesidades que tendremos en el día a día. Quiero dar las gracias a todo el equipo de Assembler Institute por su accesibilidad y disposición para grabar éste podcast y especialmente a Cristian por someterse a mi tortura.

Hoy hablamos de un interesantísimo proyecto de formación en programación creado por CRISTIAN FONDEVILA y KASIA ADAMOWICZ . Se llama ASSEMBLER INSTITUTE OF TECHNOLOGY y podéis encontrar toda su información a través del siguiente enlace: https://go.assemblerinstitute.com/keB En un mundo cada vez más tecnológico éste área es un campo con muchísimo futuro tanto por las posibilidades en el ámbito laboral como por las necesidades que tendremos en el día a día. Quiero dar las gracias a todo el equipo de Assembler Institute por su accesibilidad y disposición para grabar éste podcast y especialmente a Cristian por someterse a mi tortura.

Un ancien policier détourne un jeu organisé par McDonald's et vole des millions de dollars. Son nom : Jerome Jacobson. Découvrez sa True Story. Qui n'a jamais triché pour gagner au Monopoly ? Parmi les techniques, voici une : portez-vous volontaire en début de partie pour être banquier. A chaque fois que la banque vous doit de l'argent, piochez un ou deux billets supplémentaires. Comme la technique de Jerome Jacobson pour gagner des millions à un jeu organisé par McDonald's aux Etats-Unis. Un jeu Monopoly justement, pour lequel chaque client reçoit une vignette à son passage en caisse. Le but ? Assembler des cartes propriétés pour gagner un jeu vidéo ou de l'argent. Il est aussi possible d'obtenir une carte gain instantané qui donne droit à un Big Mac ou… 1 million de dollars. Ecoutez la suite de cette histoire incroyable dans ce podcast. Pour découvrir d'autres récits passionnants, cliquez ci-dessous : Oprah Winfrey, du ghetto au sommet L'affaire du col Dyatlov, le cold case russe devenu un mythe Casanova, le séducteur aux multiples visages Learn more about your ad choices. Visit megaphone.fm/adchoices

Le kinkeliba est une plante très appréciée en Afrique de l'Ouest. Dotée de bien des vertus, son goût rappelle la feuille de kaffir, et fait merveille quand il est marié au goût plus terreux du mil. Le kaffir ou combava est une plante asiatique de la famille des agrumes au goût citronné. Pour 4 personnes — Préparation et cuisson : 1h15Ingrédients120 g de semoule de mil (thiakry) - 4 ou 5 feuilles de kinkeliba (verte de préférence) - 6 c. à s. de yaourt nature - 2 cuillères à soupe de sucre - (selon votre goût) 2 cuillères à soupe de lait concentré non sucré - 2 cuillères à café de fleur d'oranger - 120 g de fruits rouges.La recette du thiakry parfumé au kinkelibaFaites infuser le kinkeliba dans l'eau chaude pendant quelques minutes.Mettre la semoule de mil dans un bol puis verser le kinkeliba filtré et très chaud.Couvrir pendant 15 min.Dans un bol, mélanger le sucre, le yaourt, le lait concentré et la fleur d'oranger, et réserver au frais pendant 1h.Assembler en disposant la semoule de mil au fond d'une assiette creuse, recouvrir de crème, parsemer de feuilles de menthe et de fruits rouges frais.Recette de poche est un podcast proposé par RFI avec l'envie d'utiliser des produits locaux africains connus, ou pour le plaisir d'en découvrir de nouveaux, de bons produits cultivés sur le continent, destinés à l'exportation, et qui ne demandent qu'à se faire une place dans les cuisines africaines.Ces recettes sont imaginées par le cuisinier mauritanien Harouna Sow, traiteur et chef formateur pour le Refugee Food, à Paris. Chaque épisode est une nouvelle recette de poche facile à réaliser, originale, avec ce goût-là, qui régalera vos proches, vos amis vos voisins.Cuisiniers de tous les jours ? Amateurs ou passionnés ? Vous avez des produits que vous ne savez pas cuisiner ? Des recettes à partager ? Contactez-nous en ligne pour cuisiner ensemble !Recette de poche est un podcast original du Goût du monde pour RFI - Production : Clémence Denavit ; Réalisation et mixage : Cécile Bonici.

About W. Coy Gauthier and Software Consulting Services, LLC: Coy Gauthier founded SCS, LLC in 2003. In his role as CEO, Mr. Gauthier has worked to revitalize the technology industry within the Jackson Metropolitan and surrounding areas by providing efficient solutions to complex problems. Coy has over 24 years of software development experience beginning as a C++ and Assembler developer at Exxon Chemical Plastics and going on to work for some of the world's largest corporations including Exxon Chemical Americas, Entergy Nuclear Power, and AT&T. Through these experiences, Mr. Gauthier has mastered the craft of provisioning the right combination of Business Intelligence and Information Technology to meet today's demanding strategic business planning and evaluation needs. In 2017, Coy was one of a select few to receive the Mississippi Business Journal, Top In Tech Award in recognition of his contribution to driving the technology industry in Mississippi. Software Consulting Services (SCS) was founded on the beliefs that Information Technology strategies and solutions should be carefully scrutinized, routinely evaluated, and should never be a mystery to management. We believe that the foundational elements of business and technical strategies should be architected by professionals who have the experience and expertise to respond to new and existing threats and opportunities. We employ a holistic approach whereby, SCS not only meets the current needs of our clients; but we also explore avenues that prepare clients for the future. By focusing on your current needs and your strategic goals, we are able to provide network and software solutions uniquely customized for your business.

 If we understand Mozart then we can get a broader understanding of the divine. And we skip the morality about sexuality and profanity. Mozart was such rascal and genius to the same time.Mozart was obsessed with sex and cracked, dirty, profane jokes, without even thinking of the consequences of his bad behavior…Even he did openly sex in public toilets… There is no ending of his misconducts...  With 4 years he started to compose, with 7 years he had composed already a complete concert…Mozart composed also dirty songs, for instance: Leck mir den Arsch Fein recht schön saber. (I refuse to translate)Can you do such thing?And he never had corrected any note that he composed.Mozart could write entire concerts out of his mind, without correcting anything.Amadeus Mozart was a channel of the Lord…How does such thing work out…?If we are totally relaxed and open mind, only then the Lord can choose us as a channel.What I described in a previous blog, within an instance of a second, I got so deep insights and great solution when I was under the shower.I had designed the hardware for the satellite navigation system already and the software was missing and I was running out of time… Within 3/2 hours I wrote down the complete program in Assembler (microprocessor language) just so. For that task I would normally need 6 weeks… For sure, I had to correct this program, because I am not a genius… At this time, I had also an awesome sexual life, that made me so relaxed… I lived for 10 years in an Ashram and watched the absurdity of a perverse system…To create so many rules to live in chastity (abstinence…) a religious life…So, more rules so more the rules were broken, at the end who cared/cares in an ashram, monastery for rules? The Guru/Abbot looks that his disciples keep the rules and he/she is breaking the rules/morality by him/herself.Morality is for the others, never for yourself. (Oscar Wild)When I was attending a worship of God in an African church, then Jesus was coming.Did we chase purity? We were dancing and singing the praise of the Lord like crazy.The priest was yelling and even rolling on the ground when he broke out in anger…Such madness and divine…The church was filled with so much spirituality, that Jesus had to come.And that should happen in every church or temple.A religious system that is obsessed with absurd rules will never connect to the Lord/divine, even more it will prevent love and spirituality...And we can watch the religious fanaticism, that kills/killed so many people…For what are the Religions good for? My video: Can we understand God? https://youtu.be/uu_pFdsjhkQMy audio: https://divinesuccess.net/wp-content/uploads/2021/Podcast1/Can.we.understand.God.mp3

How the definition and mechanisms of building valuable content are shifting.

Pour en savoir plus sur comment trouver le bonheur et remplir ta vie d'épanouissement, je te donne rendez-vous sur : https://www.sylvainviens.com/ Très souvent, on s'embourbe dans nos problèmes sans chercher la solution. Si je te disais que là, tout de suite, tu as tout ce qu'il te faut pour être heureux, épanoui et accompli. Maintenant, il te faut juste les assembler. Dans cet épisode, je te donne 6 conseils (environnement bienveillant, définir un cadre, se focaliser, faire une pause, prendre de la hauteur et se faire aider) pour que ta vie devienne plus heureuse dès la fin de cet épisode. Tu veux en savoir plus, n'oublie pas la 

Sarah Jérôme, artiste plasticienne, est l'invitée du 9ème épisode de Femmes artistes / Artistes femmes le podcast.  Avec elle, nous avons parlé de son parcours de femme et d'artiste, du fil rouge qui inspire son travail, du cœur de son quotidien, et de sa « grotte » basée à Montreuil dans laquelle elle concocte des œuvres et assemble des matières : la peinture à l'huile et le papier calque, la cire et la céramique, le tissu sur papier… Son œuvre, à la fois sombre et candide, abstraite et figurative, prend tout son sens au regard de sa narration. En quête d'une reconciliation de âmes et des matières, les couleurs de Sarah Jérôme se superposent, en couches, et laissent apparaître des images dont l'harmonie semble sourdre du chaos. Cet épisode est une ode à nos ambivalences... Artistes qui inspirent son travail : Les symbolistes, Louise Bourgeois, Marlène Dumas, Pina Bausch, Berlinde De Bruyckere, Guiseppe Penone, Patti Smith, Katharina Ziemke Références littéraires Une femme de Anne Delbée (biographie de Camille Claudel) ; La femme qui tremble de Siri Hustvedt ; Le mur invisible de Marlen Haushofer ; Poupées de Éleonore Pourriat Expositions à venir : Duo Show avec Gael Davrinche (qui aura lieu début juin à la Chaufferie de l'Antiquaille à Lyon) et exposition We love witches à la galerie Sabine Vazieux à Paris, décalée en décembre 2021 Oeuvre décrite en intro de l'épisode :  Solace (2018) Technique mixte sur papier calque 180 x 137,5 cm Le site internet de Sarah Jérôme : www.sarahjerome.com et sa page Instagram @sarahsaje.jerome Les galeries avec lesquelles elle travaille  Galerie Vachet-Delmas, Galerie Sabine Vazieux, Doppelgaenger, Galerie Da-End  Suivez-moi sur la page instagram du podcast @artistesfemmeslepodcast et sur mon fil twitter @adakafel. Femmes artistes / Artistes femmes est un podcast entièrement indépendant créé et produit par Ada Kafel. Ada Kafel est artiste peintre et maman d'un petit garçon. On peut voir son travail sur son site internet https://www.adakafel.com/ ou sa page instagram @a_felka. Musique d'introduction : Leonie Pernet, Butterfly feat. Malik Djoudi Musique de fin : Ruppert Pupkin "Dans ma peau, On ne tue jamais par amour". Un film tourné en confinement de Bruno Merle et Ruppert Pupkin. 

Meet Seth. He's an assembler. With his certificate in Airframe & Powerplant, his path led to a position as an Assembler. His favorite tool? A profilometer. Listen and learn about his path as Seth talks shop. FOLLOW ON INSTAGRAM // FACEBOOK

Show Notes: 01:02 - Why outside-in development? 05:50 - Best Practices and Implementation 09:35 - API Iteration and Design 18:31 - Is outside-in development a timeless approach to software development? 24:10 - Outside-in Creation 28:37 - Summarizing Outside-in Development and What it means to the Frontside Resources: Sketch InVision Balsamiq pretender Ember CLI Mirage bigtest Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast episode 96. My name is Charles, I'm a developer here at the Frontside. And your podcast host in-training with me today is Jeffrey. JEFFREY: Hello. CHARLES: Hello, Jeffrey. And Arash. ARASH: Good morning. CHARLES: Yeah, how are you doing? ARASH: Doing great. Thank you. CHARLES: All right. So, today this is going to be a little bit of an internal powwow where we're just going to talk about some of the patterns that we see as we develop software and just kind of a little bit of a chat on the way we do it. So, we're going to be talking today, I guess we could do like a little bit of a spoiler and just kind of co lead with what we're talking about. ARASH: Which is... CHARLES: Which is... ARASH: Drum roll... CHARLES: Outside-In development. And it's kind of the way that we've just naturally gravitated towards, towards developing software here. ARASH: So first question is why we gravitated toward that. CHARLES: I could just tell you kind of our personal history on this. Is that, I guess it was, would you say like around 2007, something like that kind of the pattern of like REST services got like really well established. ARASH: Sure, that's accurate enough. CHARLES: Yeah. It's like around mid-2000's. And so people just went kind of, you know, cuckoo for Cocoa Puffs except APIs instead of Cocoa Puffs. So it was like all the talk was about your API, what's going to be your API, and how are you going to present this to the world? And oh my goodness, you're opening up your system for extension by developers and it's really fantastic. So, it kind of became the norm, I feel, from that point forward to be thinking about what is the API that I'm going to be presenting rather than what's the application. ARASH: That's your starting point. CHARLES: Yeah, that's your starting point. So a lot of development and getting like a lot of frameworks came along to make API development really simple, regardless of run time. It was really just really simple to just set up API. And so, a lot of people did that and I think there was value in that and that you're thinking kind of about your external domain model, like how you're going to present yourself to the world. And so you really are focused on the constraints and the abstractions that you want to present and how you want to hide all the messy complexity behind your system. But the problem that you get into is in those days, especially on the web, the clients were very closely aligned with the APIs. If you're coming like from a Rails backend, you almost had one for one between your pages and your API. If I've got a user's end point, I'm going to have a user's management page. And I think as clients became more stateful and more of the kind of interactions were ported over to the client, that synchronization and one to one mapping between what your API look like and what your interface look like, that started to crumble and disintegrate. And now I think that it's actually quite, I mean there are still clearly analogs because you're talking about the same entities. But your client is really now a full-featured application. And it's got complex rendering logic, it's got complex state management, it's got all these things that happened completely and totally separate from your API endpoints. JEFFREY: And your UI ends up being aware of relationships between models. So yeah, it's just so much more sophisticated than what we used to need to do when everything was server-side rendered. When you're dealing with a heavy client side app, your API needs to be quite a bit more flexible really. CHARLES: Right. And so what we were finding was that we'd often have to change the API significantly in order to support complex interaction on the client. But the problem is, is if you've started with your API, you've invested a lot of development, you've invested a lot of design and you've really laid down not just that design, but also the infrastructure and the operations to make it real, it can be very hard to change. And so, it can exclude a lot of the desirable interactions that you would like to have merely by virtue of the fact that it's set in stone. So I think that's kind of why we found ourselves... JEFFREY: Why we discovered that inside out wasn't quite working for what we're doing anymore. CHARLES: Yeah, exactly. It was like having a rock solid API was actually a drawback rather than an asset, whereas 10 years earlier it was an asset. And so it really, kind of having that insight made us step back and wind it back and say, "OK, where is the natural starting point? Where do we want to start?" ARASH: So philosophically, what does Outside-In development mean to the Frontside? JEFFREY: It means that instead of starting with the API, looking at actually the workflow is instead we start with what's the UI. What is the client side app going to look like and what are the needs of that client side app? And that drives the development of the API rather than solely, I guess you could say, the business models that would have previously been the initial driver for what that would look like. CHARLES: Right, exactly. Letting the business models be kind of a function of the desired interaction or the desired experience and then letting it proceed from there. So really is yeah, it's starting from kind of what does the person using your system going to touch rather than what is the computer using your system going to touch. ARASH: And so if one of our listeners is interested in Outside-in development, what kind of tenets would you recommend they follow and what are some of the best practices you can put into place to align well with this kind of thinking that we're talking about here? CHARLES: I think that's a good question because there's obviously the philosophy of it, but then there's the practice and the implementation and what does that mean. And there's a lot. There's a lot of just kind of the way you approach the problem and then the tools that you're going to use. I don't know, Jeffrey, which ones should we tackle first? JEFFREY: Let's tackle the tools. Why not? We'll go backwards. We probably should cover other things first, but why not? CHARLES: We'll tackle the tools? All right, and this is actually a question I want to throw your way too is at what point do you...because you want to start really with having a good design, like a good wireframe? Do you prefer to start with say like something in InVision or Sketch or do you like to proceed straight to a working implementation? JEFFREY: For me, it usually depends on how complicated of an app it's going to be. If it is something that's, I'm just dealing with like some crud operations, a lot of times I'll just go straight to the HTML and like starting to build that in actual JavaScript and we'll probably talk about the fake backend for that. But yeah, it versus something that's a little more complicated that has maybe a more novel approach or particularly interesting workflow or something that's going to be pretty difficult to code. That's when I'll start on in Sketcher, InVision, or a tool like that. CHARLES: I think in the last project, we used Balsamiq. I mean, we don't want to get caught up on like tools, but I think that's a great tool because the other thing we did is it wasn't just one designer doing it. We actually had all of our developers going and writing Balsamiq sketches for the features that they were going to be implementing because it really means that they're going to actually put themselves in the shoes of someone using it and they're going to be thinking about what it's like to be a user. Because they've got to start drawing the boxes and lines and the buttons that people are going to click in and the text fields in which they're going to communicate with the system. JEFFREY: And what was awesome about using a sketchy type of style like Balsamiq is that it removes the developers from thinking too much about having to make sure this headline is exactly the right font size, that I'm using all the exact right colors. Like, don't worry about that yet. Let's just get the wireframes in this sketchy style first and then we can work from there. CHARLES: Because it really is. It's very valuable to have this process for yourself as one single developer to be able to view it from the outside in. And I think that looking at it one way, that's truly what it means to be full stack is that you can put yourself in the shoes of every piece of the system at each point. So I can put myself in the user's shoes, I can put myself in the client's shoes. When I say 'client', like the actual browser, the browser's shoes. I can put myself in the server shoes and I can have that perspective of each part. JEFFREY: So that got me thinking about what browsers would wear what kind of shoes, but we'll leave that conversation for another time. Who'd wear the Chrome shoes? ARASH: Chrome is definitely Nike, for sure. Speed. JEFFREY: So back to the tool. CHARLES: Just like Safari, like Hugo Boss. ARASH: It's like, yeah, that's pretty close. Netscape is like K-Swiss or something like that. CHARLES: It's got to be some defunct brand. ARASH: BK Knights. JEFFREY: Mosaic is the LA Lights. CHARLES: Those were great. JEFFREY: So once I have this design, I'm starting to move to code and I'm starting to build some UI, how can I iterate on my API from there? Because I'm starting to actually build a real app, I want to connect to something, I need a data store. What can I do there? CHARLES: We've talked about this a lot, I think on this podcast, really over the years. And this is a technique that we got from the Ember community. There's a stack of fantastic libraries. There's Pretender which allows you to stub out XMLHttpRequests using a DSL, kind of like Node Express. And then based on top of that, there's basically an entire fake API layer which allows you to build, I would say it's not even really a stub at this point. It's like actually a prototype server implemented entirely in your browser. It's called Mirage. JEFFREY: So, you think about it, almost like starting in Sketch and then going to HTML. You're starting in some pretty simple JavaScript and then you're working your way up to what that API design looks like. CHARLES: Right. And so that lets you experience all of the nuance of API designs. So it comes with like you can experiment with different serialization formats, what are my property's going to look like? You can experiment with how do I load related data? So, if I've got a list of users and I want to get all of the comments that they've ever posted on my site, you might want to load those at the same time. So whether your API's going to support that and how it's going to support that, you can't really know until you actually have a consumer of that API. So what Mirage lets you do is it lets you consume an API you haven't written yet and you get to feel what it's like on the client and you get to make changes to that interface at a very, very low cost. So there's no deployed infrastructure, there's no automatically generated documentation. There's no real consumers yet. There's no multiple clusters running in the Cloud and it's very, very, very lightweight. It's just running right there in the browser. And so what that lets you do is if you have an insight about the shape of the API, it lets you validate that insight. Or if you have an assumption that you have about your API that actually is going to be detrimental to your experience, you get to have that assumption invalidated very quickly. And so at the backend of this process, you end up with a backend that is optimally shaped to serve the experience that you're shooting for. ARASH: So once you've got that, how do you reconcile it against is this a good API that I want to expose externally because maybe it's not. CHARLES: Like what do you mean? ARASH: Imagine that we've built the UI and we've iterated on the API in a fake stubbed way with Mirage or some similar tool and we've got to a state that we're pretty happy with, with the API design that works for this UI. Now, imagine we want that API to also be available to other things. CHARLES: Right. ARASH: How do we reconcile that? CHARLES: That's actually, I think that's kind of an open question right now, right? I mean, we don't really have a good answer to it because it is a stubbed API. And ultimately you're going to have a real API. So at some point, you do have to say like, this is the shape that I want. I'm going to go ahead and create these things and I need to make sure that those two APIs actually line up. Is that what you're asking is like, how do I make sure that they line up? ARASH: Sure. That's one piece of it. CHARLES: Oh, that's one piece of it. OK, so this is actually...we'll explore this process. This is actually like a problem, I think, with the stubbed approach is you have your set of stubs and then you have kind of the real McCoy which eventually will come along. So, it's great to have a server running inside the browser, but at some point you're going to need an actual server that's running in the Cloud. ARASH: Will you? Like what does the future hold? CHARLES: I mean, yes because the data needs to move, right? The data needs to move off your laptop. Honestly, Arash asked a good point if you're making an offline application. So if you're making an offline application, this actually allows you to bring a persistence architecture to the browser that is like every other... you don't have to make a special one off case. You can treat your backend like a backend. It's just running on the frontend. So that's probably a corner case, but it's worth pointing out that there used to be like back in the day, if you're using something like Microsoft Word or Excel or some other offline app, you can go a long way without having any internet connectivity, but you get to build it in exactly the same way. And then when you are ready to have internet connectivity, you've got the architecture in place. So, the future might not hold that and you might actually be able to use this in production. I would say it's a minority of cases. Most time you actually are going to want to have a server component. Let's say that you do, now you've got your real API and then you've got your prototype API that you run your tests against or that you're running against, and they need to line up because your frontend is going to be using both of them kind of throughout the development process. So there are a couple of strategies to deal with this. I'd say one is you run automated tests against both versions and that's a whole another subject of having testable APIs. Like most APIs that we have that we develop aren't set up to do end to end testing including a lot of the ones that we've written, although I think going forward now that we have a better handle on it, we can do that. We can definitely unpack that subject at some later point like making testable APIs. But I would say that the other strategy that you can use is use some sort of third party verification mechanism where you essentially record a bunch of interactions between your application and the fake API. And then you take those recorded applications and have them in some sort of repository and you can play them back on your real API and make sure that the responses generated by your real API for those recorded interactions to match up. So it's kind of like, I don't know, it's just a machine to make sure that the APIs stay in sync. ARASH: That's a domain that we need to get better at. CHARLES: Yeah. ARASH: We're only scratching the surface there. CHARLES: We're definitely only scratching the surface there. But the power of being able to develop without a real API first is enough so I think it makes the exploration warranted. There are some established tools in this space. The biggest one that I know of is called Pact. It's both a library and a repository. So it's kind of like got a...I don't know if there's a central server for it, but it's kind you record interactions, you upload them to a Pact server and then you can verify. So you can actually have a lot of consumers. And so, it's designed not only for making sure that your stubbed API works, but it's also for making sure that you just don't make breaking API changes. You can actually collect a lot of data about how people are using your API and then you can use that as a repository for when you make a change in your API to verify that'll work for all these other people. So if I'm just some random person or some random developer using your API, I can...kind of like how you record [inaudible] statistics and stuff to make the Apple experience better or whatever. It's very common for developers to ask, to record for certain anonymous data. You can submit anonymous data in the form of like Pacts. And so that can help an API developer verify whether the change they're going to make is going to break clients out there. So that's a little bit of a sidetrack there, but it's something that you start to think about a lot more when you start to develop in this fashion. ARASH: Did you feel like Outside-In development is a timeless approach to software development? CHARLES: I do. I feel like Outside-In, it actually even pervades more of software development than actually like the building the software. Like I feel that the longer you go in software development, you realize that the highest value activity is to front load understanding. So whether you're submitting a pull request, whether you're working on a work ticket, whether you're documenting code or even writing a method, the highest value activity that you can be engaged in, in each one of those points is understanding what the hell you're doing. ARASH: And why, too. Right? CHARLES: Yeah, exactly. Why? Understanding the motivation. What's your prime directive? What is the context on which you're entering into this piece of work? JEFFREY: I'm going to go with a bit of a contrarian approach. CHARLES: OK. JEFFREY: I'm going to go with a "maybe"... CHARLES: Maybe? JEFFREY: Maybe this is timeless. CHARLES: Maybe it's timeless? JEFFREY: Because I think historically, so much of software development was working with constraints. And the particular types of software that we're working on, the most important constraints are on the frontend. What does the end-user experience look like? But historically, that hasn't been the case. Historically, the primary constraints have been what can this technology stack that I'm working on actually do? CHARLES: Like what is the computer experience that I can support. JEFFREY: Yeah. And so that was actually the bulk of the work was like how can I actually get something that I want out of this giant machine in a room with me? So, maybe it is timeless, maybe not. But I think it is the way going forward. CHARLES: OK. So I agree that there's an interplay. There is kind of a yin and yang cycle. And I don't mean the cycle of we go to where we have to think about this and then we go to where we have to think about that. But I take your point, Jeffrey, but I think of something like Super Mario Brothers, which is I would say both a miracle of experience but also a miracle of technology in the sense that I think it was hand coded in Assembler on an 8-bit controller with who knows how much memory, the whole thing. So taking that into account, they had to think very strongly about what the computer could do at that point. They were operating under some just incredible constraints. But at the same time, they were thinking about what...they very clearly were focused on what is the coolest game that we can make at this point. So you're absolutely right. You have to hold both inside your head. You don't want to go crazy. I mean, we could sit down on the Balsamiq thing and be like, the first thing we're going to do is we want a VR room with...okay, no. Let's dial it back. JEFFREY: How do you wireframe VR? I've never seen anybody try do that. CHARLES: The Frontside Podcast episode 97: Wireframing VR. JEFFREY: Interesting. CHARLES: How we wireframe VR. So yeah. I agree. I take your point. You do have to hold both in your head at the same time. But I would say start with one a little bit and then see where that can take you, that the task of gaining understanding about what you're trying to build [inaudible]. JEFFREY: Yeah. CHARLES: If you try to understand what you're trying to accomplish, then you can try to push the tech stack towards that direction and maybe push a little progress forward. And then if you've accomplished something that you couldn't accomplish before, then you can start dreaming about even better experiences. And so kind of moving...like the wheels on He-Man's magic bus or whatever. JEFFREY: This is out of my domain. ARASH: I'm so [inaudible] backwards right now. JEFFREY: Our references are not timeless. CHARLES: Haven't you seen the...what's the one where he's like singing the song like the 4 Non Blondes song? And I said, hey, yeah, yeah. You haven't seen the He-Man, like the cover of 4 Non Blondes? ARASH: Oh, like they dubbed his... CHARLES: Yeah, no one's seen it? Oh, man. ARASH: It's starting to sound familiar. CHARLES: OK. I mean, this is like we're talking... ARASH: This is like 2006 internet? CHARLES: No, this is like 2010 internet. It's not the ancient past here. ARASH: I'm going through my internet filing cabinet in my brain right now. CHARLES: Okay. It had particular significance because the friends from attorney were also part of my childhood and I realized I'm unique in that aspect. But they basically, in those days they had the Hanna-Barbera cartoons were very cookie cutter, so they basically took the Mystery Machine from Scooby-Doo and they kind of re-colored it and they put like weird tank treads that like they put really funky kind of weird futuristic He-Man wheels on it. And it went from the Mystery Machine to He-Man's kind of a ride. ARASH: They repurposed all the illustrations. CHARLES: Exactly. Hey, you got to save time. ARASH: Save time somewhere. CHARLES: Doing your framework. ARASH: Kids need cartoons. CHARLES: That's right. So anyway, that's how the wheels on He-Man's Mystery Machine worked. ARASH: This has been interesting for me because when we first started this conversation, we're looking at it as Outside-In development. But we've talked so much here about design and creation that it almost starts to feel like Outside-In development is almost too narrow. Like it's really what we're talking about here is Outside-In creation of anything useful and valuable to people. CHARLES: Yeah. It's easy to overlook like whenever you want to create something, you get so focused on the actual building of it or the making of it happen that you kind of lose sight of where it is that you're going. And I think that sometimes it's important to be able to create without knowing where you're going to kind of push the paint around the canvas, so to speak. I think that's a valuable activity, like sometimes it's important to just code without really having any clear direction. You're just kind of following your instincts. Then it's the same way you look at Picasso's study in charcoal or whatever. There'll be like a picture of a horse leg and Picasso's like, "Oh, there's a horse leg. Man, how do I capture a horse leg?" And not really having much intent. And so that's important. But I think when you're building systems or you're creating something that you want to have a real lasting impact, you do need to consider it holistically and you really need to understand why it is that you're doing what you're doing. JEFFREY: Part of what's awesome about working in software is that unlike Picasso who had to start a new piece, we can keep working on the same piece and be able to paint over it multiple times. And you can start with that outline of like, "Hey, this is the vision that we see this particular thing going." But then don't make space for like, "Let's just push the paint around and see what happens in this little section," and that's fine. CHARLES: Yeah. And I think that because software is so malleable that it can end up capturing a lot of what is typically considered design. I think this has kind of also been a theme that we've talked about kind of over the last year or so is that over the last 20 years we've kind of seen software capture a lot of what were once separate practices. So when I was first starting out, it was quality. The line between QA and development was very stark certainly at the beginning of my career. And there was a fusion that was happening right as I joined of QA and development. And we saw basically the testing revolution, realizing the testing needs to be brought into the center of development, which needs to be put forth first if you want to have quality, be something that you want. And then, a revolution that I saw kind of in the middle of my career is seeing operations. It used to be certainly for many years into the beginning of my career, like the people who maintain the software were very different from the people who wrote it and there was a big divide there. And with the Dev Ops movement, it's kind of the realization that no, if we want to have healthy operations, we need to understand what healthy operations are at the very beginning and we need to like put them at the beginning of the process. And I think that what we're seeing now, maybe a revolution that hasn't quite happened yet, but we're on the cusp of is seeing design burrow its way to the heart of development where it's like we want something to be beautiful. We want it to be frictionless. We want it to be delightful to its end users. It needs to be there from the get go and developers need to be thinking about it. It's not someone else's responsibility. It's you as the primary creator. JEFFREY: It doesn't matter how elegant of an API you've created if the end user experience is just not there. CHARLES: Yeah. So it's all about tearing down. There's been a series of walls that have come down that I've witnessed. And so I think this is one that's in the process of crumbling. ARASH: So, this has been an awesome talk. How would you summarize Outside-In development and what it means to Frontside today and in the future? CHARLES: I think that it really is about making sure that the understanding is solid. That's the core piece, frontloading understanding, realized through a stack of tools. So the tools we use are some sketch and design tool. We'll sketch out the idea we really like, ask questions and try and understand it and firm up in our idea, like have a vision of what the experience is going to be like. Then the next step is to write some acceptance tests. So to define done, define what your criteria are going to be so that if I run these automated tests, the code will in fact realize the experience that I'm dreaming about. To do that, we've actually been assembling a suite of tools over the past year to do that and we've actually started releasing them to the world. So, it's still in a...I don't want to say alpha because we're using them in production systems, but it's much more of a work bench at this point than a framework, if that makes any sense. So we have about four related tools under the big test tent. We have interaction library for stubbing out, gestures, mouse clicks, keyboard events, scrolling. We have assertion library that works with any other source. It's really an assertion extension or extension wrappers to make your assertions impervious to asynchrony. We've extracted Mirage from Ember CLI Mirage so that you can use it in any project, React, Vue, Ember, what have you. You can check it out at big test. It is for early adopters right now, but it is in production systems and if you want to acceptance test anything, command line, back client, what have you, if you're willing to write some JavaScript, you can write those acceptance tests and have them be robust. And whatever experience you're trying to create, you can validate it with that. And so, that's why we created it. JEFFREY: And that's really a good marker of where we are in our experience with Outside-In development right now is we've been doing this in practice for awhile at this point and we're crafting tools to help us be even better at it and sharing those. CHARLES: Right. And so we're pretty excited about these tools because I think they bring solutions to a lot of the problems you're going to encounter. So there's a lot more work to do and we're excited to do it. Head on, check those out. And we'll go ahead and wrap up. Just a few quick announcements. If you're going to be at Assert(js) tomorrow, the Frontside is going to be there. I'm going to be there. Mr. Wil Wilsman is going to be there. So if you're there, please do give us a shout and we'll hang out. And then on the next podcast, we are really, really excited. I'm both nervous and I just can't keep a lid on it. We're going to have Erich Gamma on the podcast to talk about the language server protocol that he's been working on. If you don't know Erich Gamma, he's one of the Gang of Four that wrote The Design Patterns Book. He was the primary architect behind Eclipse and most lately VS Code. So, if you've used any of those projects or benefited from them, which I have benefited immensely from all three, it's going to be really, really exciting. So, that's something to look forward to. And with that, I will say goodbye to you, Jeffrey. JEFFREY: Ciao! CHARLES: And to you, Arash. ARASH: Adios! CHARLES: And everybody listening along at home or in your cars or cleaning your kitchen as I do when you listen to podcasts, we'll see you next time. If you want to get in touch with us, you can always give us a shout on Twitter, we're @thefrontside or you can drop us a line, contact@frontside.io.

This episode was recorded 6 May 2014 live and in person at Brent's office in lovely, sunny Ballard. You can download the m4a file or subscribe in iTunes. (Or subscribe to the podcast feed.) Chris has worked at Adobe and as a founder of Rogue Sheep, which won an Apple Design Award for Postage. Chris's new company is Aged & Distilled with Guy English — which shipped Napkin, a Mac app for visual collaboration. Chris is also the co-host of The Record. He lives on Bainbridge Island, a quick ferry ride from Seattle. This episode is sponsored by Tagcaster. Tagcaster is not just another podcast client — it solves the age-old problem of linking to specific parts of a podcast. You can make clips — short audio excerpts — and share them and link to them. After all these years, that problem is finally solved. This episode is also sponsored by Igloo. Igloo is an intranet you'll actually like, with shared calendars, microblogs, file-sharing, social networking, and more. It's free for up 10 users — give it a try for your company or your team today. This episode is also sponsored by Hover. Hover makes domain name management easy. And it's a snap to transfer domains from other registrars using their valet service. Get 10% off your first purchase with the promotional code PANIC. As in “Don't Panic! Use Hover.” Take a look. Things we mention, more or less in order of appearance: Oklahoma Wikipedia The shopping cart Rust Homestead Act Pong Atari 2600 President Carter Pinochle Republicans Democrats Apple II Apple II Reference Manual Floppy Disks Odyssey: The Compleat Adventure Marco Epson MX-80 dot matrix printer Parallel port BASIC Apple II graphics modes LiteBrite Apple II Star Wars game Assembler Text adventure games Paper app Graph paper Merlin assembler Pascal compiler for Apple II Locksmith for Apple II Apple II copy protection Radio Shack ROM chips Tin foil Alligator clips The Complete Graphics System The Incomparable Mike Lee on The Record SATs University of Oklahoma LaserWriter Linotronic image setter The Clampetts The Joads Seattle Las Vegas Belltown Capitol Hill Everett Queen Anne Magnolia Adobe Microsoft Windows X-Wing video game 8086 Assembly language Microsoft DOS Sierra On-Line PowerBook Duo Apple IIGS Think C Sega CD-ROMs Postscript Pagemaker Quark Aldus Pioneer Square 1995 Java Natural Intelligence Roaster IDE Illustrator QA Partner Test-Driven Development InDesign COM Matt Joss Version control 2001 SourceSafe Visual Studio C++ OpenDoc Resource Compiler Sharepoint Azure FrameMaker Rogue Sheep CMYK separation Optical character alignment University of Washington HITLab Gel Electrophoresis Jeff Argast PowerPoint Western blots The Guardian Bush Administration Postage Twitterrific Brad Ellis Lehman Brothers Jake Carter Cocoa Quartz Composer Motion After Effects Kyle Richter Ian Baird IAP Rickenbacker's The House of Shields John Gruber Dave Wiskus Napkin Guy English Thomas Unterberger C4 United Lemur World Cup Brazil WWDC San Francisco NetNewsWire 1999 Eddy awards

This episode was recorded 17 May 2013 live and in person at Omni's lovely offices overlooking Lake Union in Seattle. You can download the m4a file or subscribe in iTunes. (Or subscribe to the podcast feed.) Tim Wood, CTO of The Omni Group, talks about how Omni got started and what it was like being a NeXT developer before the acquisition. This episode is sponsored by Squarespace. Easily create beautiful websites via drag-and-drop. Get help any time from their 24/7 technical support. Create responsive websites — ready for phones and tablets — without any extra effort: Squarespace's designers have already handled it for you. Get 10% off by going to http://squarespace.com/therecord. And, if you want to get under the hood, check out their APIs at developers.squarespace.com. This episode is also sponsored by Microsoft Azure Mobile Services. Mobile Services is a great way to provide backend services — syncing and other things — for your iPhone, iPad, and Mac apps. If you've been to the website already, you've seen the tutorials where you input code into a browser window. And that's an easy way to get started. But don't be fooled: Mobile Services is deep. You can write in your favorite text editor and deploy via Git. Regular-old Git, not Git#++. Git. Things we mention, in order of appearance (more or less): Atari 800 BASIC Tacoma, WA Commodore Apple II 6502 Assembler Atari ST Compute! Magazine Burroughs Mainframes Radio Shack NeXT Mac University of Washington H19 Terminal Fortran Mathematica LaTeX Java Ada Boeing Department of Defense VMS IBM 360 Objective-C AppKit Interface Builder Project Builder Makefiles Read-write Optical drives Wil Shipley Ken Case Greg Titus Tom Bunch Massively multiplayer games Minecraft MOOs MUSHes CompuServe Ultima Online William Morris Agency McCaw Cellular 1992 Framemaker Adobe Lighthouse Design Diagram! OmniGraffle 1994 www.app OmniWeb Blink tag Rocky & Bullwinkle Rhapsody Hewlett Packard Sun OpenStep Solaris Windows NT Be Jean-Louis Gasée Enterprise Objects Framework Core Data Avie Tevanian Jon Rubinstein Bertrand Serlet Craig Federighi Appletalk Yellow Box HP-UX Andrew Stone Doom Id Software Wil's mail OpenGL John Carmack DirectX OmniOutliner Comic Life NCSA GCD Blocks Functional programming Mac Pro Go Rust Race conditions OmniPresence Own the Wheel iCloud Core Data Syncing Rich Siegel Yojimbo Sync Services

This episode was recorded 17 May 2013 live and in person at Omni's lovely offices overlooking Lake Union in Seattle. You can download the m4a file or subscribe in iTunes. (Or subscribe to the podcast feed.) Gus Mueller, Flying Meat founder, created VoodooPad (now at Plausible Labs) and Acorn, the image editor for humans. Gus is also responsible for open source software such as FMDB and JSTalk. This episode is sponsored by Squarespace. Get 10% off by going to http://squarespace.com/therecord. Better still: go work for Squarespace! They're hiring 30 engineers and designers by March 15, and, “When you interview at Squarespace, we'll invite you and your spouse or partner to be New Yorkers for a weekend—on us.” The great designers at Squarespace have designed an entire weekend for you, from dining at Alder to going to the Smalls Jazz Club and visiting The New Museum. Seriously cool deal at beapartofit.squarespace.com. This episode is also sponsored by Microsoft Azure Mobile Services. Mobile Services is a great way to provide backend services — syncing and other things — for your iPhone, iPad, and Mac apps. Write code — Javascript code — in your favorite text editor on your Mac. (Mobile Services runs Node.js.) Deploy via git. Write unit tests using mocha (or your tool of choice). Supports authenticating via Twitter, Facebook, and Google — and you can roll your own system. It's cool. Things we mention, in order of appearance (more or less): Rock climbing Luke Adamson Missouri 2001 2002 Cocoa Apple IIc 1993 Mac Color Classic BASIC ELIZA Artificial Intelligence Assembler Missile Command Java Eric Albert Perl Animated GIFs CGIs Server push images REALBasic PC Apple IIe DOS Colossal Caves Plover Nibble Civilization UNIX AIX A/UX St. Louis Columbia Math is hard Single sign-on Servlets OS X WWDC Rhapsody 1995 MacPERL NiftyTelnet BBEdit FlySketch Coffee Picasso's bull sketches VoodooPad 22" Cinema Display OS X Innovator's Award O'Reilly Peter Lewis Rich Siegel Mark Aldritt Ambrosia Panic Transmit Audion O'Reilly Mac OS Conference Audio Hijack Paul Kafasis SubEthaEdit Mac Pro Ireland XML PDF Victoria's Secret Caterpillar Adobe InDesign OS X Server Xserve Macintosh G5 MacUpdate VersionTracker QuickDraw Kerberos HyperCard Objective-C messaging system Aaron Hillegass's book Java-Cocoa bridge JDBC Oracle databases 2005 Seattle Microsoft Parents Just Don't Understand Vancouver, BC B.B. King Seattle Xcoders Joe Heck University of Missouri Evening at Adler Wil Shipley Daniel Jalkut Eric Peyton Quicksilver Rosyna Chicago Drunkenbatman Adler Planetarium C4 Wolf Colin Barrett Delicious Generation Disco.app My Dream App Chimera / Camino Santa Clara World Wrapps Buzz Andersen Quartz Core Image Filters Bezier curves Wacom Unit tests Automated builds ZeroLink Metrowerks CodeWarrior NeXT BeOS Macintosh Performa Display Postscript SGIs Sun boxes Mac OS 8 MachTen Netscape Internet Explorer for Mac OS Outlook Express OmniGroup Shakespeare's pizza Pagliacci Neapolitan pizza Everett FIOS Fender Stratocaster GarageBand AudioBus Adobe Photoshop Adobe Photoshop Elements JSTalk AppleScript SQLite WebKit Napkin