Podcasts about simple made easy

Alexander Repenning created AgentSheets, an environment to help kids develop computational thinking skills. It wrapped an unusual computational model with an even more unusual user interface. The result was divisive. It inspired so many other projects, whilst being rejected at every turn and failing to catch on the way Scratch later did. So in 2017, Repenning published this obit of a paper, Moving Beyond Syntax: Lessons from 20 Years of Blocks Programming in AgentSheets, which covers his findings over the years as AgentSheets evolved and transformed, and gives perspective on block-based programming, programming-by-example, agents / rule / rewrite systems, automata, and more. This is probably the most "normal" episode we've done in a while — we stay close to the text and un-clam many a thought-tickling pearl. I'm saying that sincerely now to throw you off our scent the next time we get totally lost in the weeds. I hear a clock ticking. Links $ Do you want to move beyond syntax? Frustrated by a lack of syntactic, semantic, or pragmatic support? Join our Patreon! Choose the tier that best reflects your personal vision of the future of coding. Get (frequently unhinged) monthly bonus content. Most of all: let us know that you enjoy this thing we do, and help us keep doing it for years to come. Argos, for our non-UK listeners. They were acquired by future TodePond sponsor, Sainsbury's. Once again, I am asking for your Marcel Goethals makes a lot of cool weird stuff and is a choice follow. Scratch isn't baby programming. Also, you should try this bizarre game Ivan programmed in 3 blocks of Scratch. Sandspiel Studio is a delightful block-based sand programming simulator automata environment. Here's a video of Lu and Max introducing it. Simple Made Easy, a seminal talk by Rich Hickey. Still hits, all these years later. Someday we'll do an episode on speech acts. Rewrite rules are one example of rewriting in computing. Lu's talk —and I quote— "at Cellpond", was actually at SPLASH, about Cellpond, and it's a good talk, about —and I quote— "actually, what if they didn't give up on rewrite rules at this point in history and what if they went further?" Oh yeah — Cellpond is cool. Here's a video showing you how it works. And here's a video studying how that video works. And here's a secret third thingthat bends into a half-dimension. Here's Repenning's "rule-bending" paper: Bending the Rules: Steps Toward Semantically Enriched Graphical Rewrite Rules I don't need to link to SimCity, right? You all know SimCity? Will Wright is, arguably, the #1 name in simulation games. Well, you might not have caught the fantastic article Model Metropolis that unpacks the (inadvertently?) libertarian ideology embodied within the design of its systems. I'd also be remiss not to link to Polygon's video (and the corresponding write-up), which lend a little more colour to the history. Couldn't find a good link to Blox Pascal, which appears in the paper Towards "Second Generation" Interactive, Graphical Programming Environments by Ephraim P. Glinert, which I also couldn't find a good link to. Projectional / Structural Editor. Here's a good one. Baba is You Vernacular Programmers Filling Typed Holes with Live GUIs is, AFAIK, the most current canonical reference for livelits. I'm not linking to Minecraft. But I will link to the Repeater 32 Checkboxes Wiremod is a… you know what, just watch this. Chomsky Hierarchy The Witness Ivan wrote a colorful Mastodon thread surveying the history of the Connection Machine. Harder Drive is a must-watch video by the inimitable Tom7. Also couldn't find a good link for TORTIS. :/ Programming by Example (PbE) Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo Alex Warth, one of the most lovely humans Ivan knows, is a real champion of "this, because that". Ivan's magnetic field simulations — Magnets! How do they work? Amit Patel's Red Blob Games, fantastic (fantastic!) explorable explanations that help you study various algorithms and techniques used in game development. Collaborative diffusion — "This article has multiple issues." Shaun Lebron, who you might know as the creator of Parinfer, made a game that interactively teaches you how the ghost AI works in Pac-Man. It's fun! Maxwell's Equations — specifically Gauss's law, which states that magnetic fields are solenoidal, meaning they have zero divergence at all points. University of Colorado Boulder has a collection of simulations called PhET. They're… mid, at least when compared to building your own simulation. For instance. Music featured in this episode: snot bubbles ! Send us email, share your ideas in the Slack, and catch us at these normal places: Ivan: Mastodon • Website Jimmy: Mastodon • Website Lu: Login • Website See you in the future! https://futureofcoding.org/episodes/073Support us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

Out of the Tar Pit is in the grand pantheon of great papers, beloved the world over, with just so much influence. The resurgence of Functional Programming over the past decade owes its very existence to the Tar Pit's snarling takedown of mutable state, championed by Hickey & The Cloj-Co. Many a budding computational philosophizer — both of yours truly counted among them — have been led onward to the late great Bro86 by this paper's borrow of his essence and accident. But is the paper actually good? Like, really — is it that good? Does it hold up to the blinding light of hindsight that 2023 offers? Is this episode actually an April Fools joke, or is it a serious episode that Ivan just delayed by a few weeks because of life circumstances and his own incoherent sense of humour? I can't tell. Apologies in advance. Next time, we're going back to our usual format to discuss Intercal. Links Before anything else, we need to link to Simple Made Easy. If you don't know, now you know! It's a talk by Rich Hickey (creator of Clojure) that, as best as I can tell, widely popularized discussion of simplicity and complexity in programming, using Hickey's own definitions that built upon the Tar Pit paper. Ignited by this talk, with flames fanned by a few others, as functional programming flared in popularity through the 2010s, the words “simple”, “easy”, “complex”, and “reason about” became absolutely raging memes. We also frequently reference Fred Brooks and his No Silver Bullet. Our previous episode has you covered. The two great languages of the early internet era: Perl & TcL For more on Ivan's “BLTC paradise-engineering wombat chocolate”, see our episode on Augmenting Human Intellect, if you dare. For more on Jimmy's “Satoshi”, see Satoshi Nakamoto, of course. And for Anonymous, go on. Enemy of the State — This film slaps. “Some people prefer not to commingle the functional, lambda-calculus part of a language with the parts that do side effects. It seems they believe in the separation of Church and state.” — Guy Steele “my tempo” FoC Challenge: Brooks claimed 4 evils lay at the heart of programming — Complexity, Conformity, Changeability, and Invisibility. Could you design a programming that had a different set of four evils at the heart of it? (Bonus: one of which could encompass the others and become the ur-evil) The paper introduces something called Functional Relational Programming, abbreviated FRP. Note well, and do not be confused, that there is a much more important and common term that also abbreviates to FRP: Family Resource Program. Slightly less common, but yet more important and relevant to our interests as computer scientists, is the Fluorescence Recovery Protein in cyanobacteria. Less abundant, but again more relevant, is Fantasy Role-Playing, a technology with which we've all surely developed a high degree of expertise. For fans of international standards, see ISO 639-3 — the Franco-Provençal language, represented by language code frp. As we approach the finality of this paragraph, I'll crucially point out that “FRP”, when spoken aloud all at once at though it were a word, sounds quite like the word frp, which isn't actually a word — you've fallen right into my trap. Least importantly of all, and also most obscurely, and with only minor interest or relevance to listeners of the podcast and readers of this paragraph, we have the Functional Reactive Programming paradigm originally coined by Conor Oberst and then coopted by rapscallions who waste time down by the pier playing marbles. FoC Challenge: Can you come up with a programming where informal reasoning doesn't help? Where you are lost, you are without hope, and you need to get some kind of help other than reasoning to get through it? Linear B LinearB Intercal Esolangs FoC Challenge: Can you come up with a kind of testing where using a particular set of inputs does tell you something about the system/component when it is given a different set of inputs? It was not Epimenides who said “You can't dip your little toesies into the same stream” two times — presumably because he only said it once. Zig has a nicely explicit approach to memory allocation. FoC Challenge: A programming where more things are explicit — building on the example of Zig's explicit allocators. Non-ergonomic, Non-von Neumann, Nonagon Infinity One of Ivan's favourite musical acts of the 00s is the ever-shapeshifting Animal Collective — of course

Доклады от гостей: Аня - React fwdays'21 • Елена Жукова • Опасный React ( https://youtu.be/ze4Qve1azA0 ) Сергей - One Hacker Way Rational alternative of Agile - Erik Meijer ( https://youtu.be/2u0sNRO-QKQ ) Кирилл - Declarative UI Patterns ( https://youtu.be/VsStyq4Lzxo ) Аня - Rich Hickey "Simple Made Easy" ( https://www.infoq.com/presentations/Simple-Made-Easy/ ) Леша (https://www.rwpod.com/) - Every Clojure Talk Ever - Alex Engelberg and Derek Slager ( https://youtu.be/jlPaby7suOc ) Миша - HolyJS Online Piter 2021 - Дмитрий Коваленко: Зачем OCaml на фронтенде ( https://youtu.be/5FdmV_H5ggk ) Дима - Best CES 2021 Smart Home Tech: 20 Awesome Gadgets ( https://youtu.be/hYJTPNyCacs ) Вова - How Do You Structure Your Go Apps — Kat Zien, GopherCon 2018 ( https://youtu.be/oL6JBUk6tj0 ) Нас можно найти: 1. Telegram: https://t.me/proConf 2. Youtube: https://www.youtube.com/c/proconf 3. SoundCloud: https://soundcloud.com/proconf 4. Itunes: https://podcasts.apple.com/by/podcast/podcast-proconf/id1455023466

Максимально детальный разбор языка Clojure: ключевые особенности, мифы, сильные и слабые стороны, экосистема, рынок вакансий и сообщество. А спорил с нами про пользу макросов и делился восторгом от мультиметодов и зипперов Иван Гришаев, программист и автор книги «Clojure на производстве». Поддержи лучший подкаст про IT: www.patreon.com/podlodka Также ждем вас, ваши лайки, репосты и комменты в мессенджерах и соцсетях!
 Telegram-чат: https://t.me/podlodka Telegram-канал: https://t.me/podlodkanews Страница в Facebook: www.facebook.com/podlodkacast/ Twitter-аккаунт: https://twitter.com/PodlodkaPodcast Ведущие в выпуске: Евгений Кателла, Катя Петрова, Егор Толстой Полезные ссылки: - Личный сайт Ивана https://grishaev.me/ - Книга Ивана «Clojure на производстве» https://grishaev.me/clojure-in-prod/ - Официальный гайд (цикл статей) https://clojure.org/guides/getting_started - Список компаний, когда-либо нанимавших на Clojure https://clojure.org/community/companies - Международный Slack http://clojurians.slack.com/ - Русские чаты в Telegram https://t.me/clojure_ru - Русский чат с вакансиями в Telegram https://t.me/clojure_jobs - Доклад Рича Хикки “Simple Made Easy” https://www.infoq.com/presentations/Simple-Made-Easy/

On this continuation of Gene Kim’s interview with Michael Nygard, Senior Vice President, Travel Solutions Platform Development Enterprise Architecture, for Sabre, they discuss his reflections on Admiral Rickover's work with the US Naval Reactor Core and how it may or may not resonate with the principles we hold so near and dear in the DevOps community. They also tease apart the learnings from the architecture of the Toyota Production System and their ability to drive down the cost of change.  They also discuss how we can tell when there are genuinely too many “musical notes” or when those extra notes allow for better and simpler systems that are easier to build and maintain and can even make other systems around them simpler too? And how so many of the lessons and sensibilities came from working with Rich Hickey, the creator of the Clojure programming language.  Bio: Michael Nygard strives to raise the bar and ease the pain for developers around the world. He shares his passion and energy for improvement with everyone he meets, sometimes even with their permission. Living with systems in production taught Michael about the importance of operations and writing production-ready software. Highly-available, highly-scalable commerce systems are his forte. Michael has written and co-authored several books, including 97 Things Every Software Architect Should Know and the bestseller Release It!, a book about building software that survives the real world. He is a highly sought speaker who addresses developers, architects, and technology leaders around the world. Michael is currently Senior Vice President, Travel Solutions Platform Development Enterprise Architecture, for Sabre, the company reimagining the business of travel.   Twitter: @mtnygard LinkedIn: https://www.linkedin.com/in/mtnygard/ Website: https://www.michaelnygard.com/   You’ll Learn About: Admiral Rickover’s work with the Naval Nuclear Reactor Core Building great architecture for generality. Architecture as an organizing logic and means of software construction. Toyota Production System’s ability to drive down the cost of change through architecture Clojure programming language Cynefin framework How to know if a code is simpler or more complex   RESOURCES Cynefin framework Failure Is Not an Option: Mission Control from Mercury to Apollo 13 and Beyond by Gene Kranz "Why software development is an engineering discipline," presentation by Glenn Vanderburg at O'Reilly Software Architecture Conference "10+ Deploys Per Day: Dev and Ops Cooperation," presentation by John Allspaw "Architecture Without an End State," presentation by Michael T. Nygard at YOW! 2012 "Spec-ulation Keynote," presentation by Rich Hickey re-frame (re-frame is the magnificent UI framework which both Mike and I love using and hold in the highest regard — by no means should the "too many notes" comment be construed that re-frame has too many notes!) "Fabulous Fortunes, Fewer Failures, and Faster Fixes from Functional Fundamentals," presentation by Scott Havens at DevOps Enterprise Summit Las Vegas, 2019 "Clojure for Java Programmers Part 1," presentation by Rich Hickey at NYC Java Study Group Simple Made Easy presentation by Rich Hickey at Strange Loop 2011 Love Letter To Clojure (Part 1) by Gene Kim The Idealcast, Episode 5: The Pursuit of Perfection: Dominant Architectures, Structure, and Dynamics: A Conversation With Dr. Steve Spear LambdaCast podcast hosted by David Koontz TIMESTAMPS   [00:09] Intro [02:19] Mike’s reflections on Steve Spear, Admiral Rickover and the US Naval reactor core [04:33] Admiral Rickover’s 1962 memo [08:13] Cynefin framework [12:40] Applying to software engineering [16:06] Gene tells Mike a Steve Spear’s story [18:58] 10+ deploys a day everyday at Flickr [19:43] Back to the story [24:34] Why the story is important [27:35] When notes are useful [35:05] Too many notes vs. too few notes [40:00] DevOps Enterprise Summit Vegas Virtual [41:35] How to know if a code is simpler or more complex [47:23] A lively exchange of ideas [51:31] The opposing argument [54:20] Implementing items of interests [55:21] Back to the payment processing example [56:07] Case 3 [1:03:03] The challenge with Option 2 [1:08:19] Pure function [1:10:19] Rich Hickey and Clojure [1:15:01] Rich Hickey’s “Simple Made Easy” presentation [1:16:37] Exploring those ideas work at the macro scale [1:22:31] Immutability concept [1:23:58] The importance of senior leaders’ understanding of these issues [1:26:53] Outro

В четвёртом выпуске Run Loop мы поговорили с Никитой Прокоповым и передали привет Илье Цареву. Илья — это наш третий ведущий, помните? А Никита Прокопов примечателен тем, что он создал Fira Code, внёс заметный вклад в развитие Clojure сообщества и опубликовал в open source такие проекты как Datascript и Rum. Помимо этого он пишет на Objective-C под macOS: Программа AnyBar подскажет о наступлении какого-либо события в status bar, ой, menu bar вашего компьютера. Помимо этого Никита рассказывает о том, что он выступает на AppsConf ‘18 с докладом «Обретение навыков» и как он пришёл к этой теме. Ссылки на проекты Никиты: — FiraCode — https://github.com/tonsky/FiraCode — Datascript — https://github.com/tonsky/datascript — Rum — https://github.com/tonsky/rum — AnyBar — https://github.com/tonsky/AnyBar — https://grumpy.website — https://github.com/tonsky/grumpy — Видеоблог о создании grumpy.website — https://www.youtube.com/watch?v=YZzkQW9Unvo. Отдельным Gist-ом собраны ссылки и описания к каждому выпуску: https://gist.github.com/zelark/a18965fbc255ea21dc9d3d1311ceda37 Лекции Rich Hickey про программирование в целом и как устроен мозг программиста: — Hammock Driven Development — http://www.youtube.com/watch?v=f84n5oFoZBc — Simple Made Easy — http://www.infoq.com/presentations/Simple-Made-Easy Вся подборка хитов от Rich Hickey: https://changelog.com/posts/rich-hickeys-greatest-hits

Шоу нотес SPA (не) нужны https://tonsky.livejournal.com/317029.html https://twitter.com/AirbnbEng/status/1019670820065402880 https://twitter.com/giacomotesio/status/1021695798072025089 Заменяем lodash используя ES6 https://www.sitepoint.com/lodash-features-replace-es6/ https://github.com/tc39/proposal-flatMap/pull/56#issue-173327251 https://www.youtube.com/watch?v=TS1lpKBMkgg String#split с блоком https://blog.bigbinary.com/2018/07/17/ruby-2-6-adds-split-with-block.html netflix/pollyjs https://github.com/Netflix/pollyjs stalniy/bdd-lazy-var https://github.com/stalniy/bdd-lazy-var Snapshot testing https://jest-bot.github.io/jest/docs/snapshot-testing.html Elements of Clojure by Zach Tellman https://leanpub.com/elementsofclojure Мемы и телепатия https://www.dropbox.com/s/tyhhwe199obd80s/distraction.jpg?dl=0 https://ru.wikipedia.org/wiki/LabVIEW Гипотеза лингвистической относительности Приватная rake-драма https://supergood.software/dont-step-on-a-rake/ https://github.com/erikhuda/thor https://github.com/ruby/rake/blob/4f9c156/lib/rake/rake_module.rb#L28L30 load.c Кому нужен RubyMotion http://www.rubymotion.com/developers/samples/ https://github.com/HipByte/RubyMotionSamples Active Interractor или нет https://github.com/AaronLasseigne/active_interaction https://github.com/thalamusai/mandate http://www.infoq.com/presentations/Simple-Made-Easy Менторство на exercism.io https://exercism.io/tracks https://twitter.com/razum2um/status/1020210374216486912 Послушал? Оставь отзыв На hardcode.fm hardcodefm@telegram + группа hardcodefm@facebook hardcodefm@vkontakte

Panel: Charles Max Wood Cory House Special Guests: Lucas Reis In this episode of React Round Up, the panel discusses simple React patterns with Lucas Reis. Lucas works as a senior front-end developer at Zocdoc and previously worked in Brazil for an ecommerce company called B2W. He recently wrote a blog post about simple React patterns that really took off and became popular on the web. They talk about this blog post, what defines a successful pattern, and then they discuss the different patterns that he has discovered in his years of React programming. In particular, we dive pretty deep on: Lucas intro Tries to write blog posts as much as possible Simple React Patterns blog post React What does he mean by “successful” patterns? Three things that define good patterns Define successful? The mix component The Container/Branch/View pattern First successful pattern he has found Separation of concerns Common concern: are we worried about mixing concerns? If/else Can you encapsulate in the view? Pattern matching React loadable You need to think of 3 states at least Higher-order component Render props And much, much more! Links: Zocdoc B2W Simple React Patterns blog post React Simple Made Easy by Rich Hickey Lucas’s GitHub Lucas’s Blog @iamlucasreis Picks: Charles FullContact Udemy Cory Fluent conf Immer Lucas Percy Be studying the languages and be inspired!

Panel: Charles Max Wood Cory House Special Guests: Lucas Reis In this episode of React Round Up, the panel discusses simple React patterns with Lucas Reis. Lucas works as a senior front-end developer at Zocdoc and previously worked in Brazil for an ecommerce company called B2W. He recently wrote a blog post about simple React patterns that really took off and became popular on the web. They talk about this blog post, what defines a successful pattern, and then they discuss the different patterns that he has discovered in his years of React programming. In particular, we dive pretty deep on: Lucas intro Tries to write blog posts as much as possible Simple React Patterns blog post React What does he mean by “successful” patterns? Three things that define good patterns Define successful? The mix component The Container/Branch/View pattern First successful pattern he has found Separation of concerns Common concern: are we worried about mixing concerns? If/else Can you encapsulate in the view? Pattern matching React loadable You need to think of 3 states at least Higher-order component Render props And much, much more! Links: Zocdoc B2W Simple React Patterns blog post React Simple Made Easy by Rich Hickey Lucas’s GitHub Lucas’s Blog @iamlucasreis Picks: Charles FullContact Udemy Cory Fluent conf Immer Lucas Percy Be studying the languages and be inspired!

Toran Billups @toranb | GitHub | Blog Show Notes: 01:44 - New Developments in ember-redux 04:23 - New Developments in the Wider Redux Community 06:26 - Using Redux in Ember 09:40 - Omit 10:45 - Reducers 25:42 - Fulfilling the Role of Middleware in Ember 28:12 - Ember Data in Redux-land 31:24 - What does Toran do with this stuff?? Links: The Frontside Podcast Episode 55: Redux and Ember with Toran Billups The Frontside Podcast Episode 18: Back-End Devs and Bridging the Stack with Toran Billups redux-offline ember-redux-yelp create-react-app "Mega Simple redux” Twiddle ember-concurrency Thomas Chen: ember-redux The Frontside Podcast Episode 067: ember-concurrency with Alex Matchneer normalizr Rich Hickey: Simple Made Easy Other Noteable Resources: ember redux: The talk Toran prepared for EmberJS DC in April 2017 github.com/foxnewsnetwork/ember-with-redux Transcript CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 69. My name is Charles Lowell. I'm a developer here at The Frontside and your podcast host-in-training. With me Wil Wilsman, also a developer here at The Frontside. Hello, Wil. WIL: Hello. CHARLES: Today, we have a special guest, an actual elite member of the three-timers club, counting this appearance. We have with us Toran Billups. Thank you for coming on to the show today. TORAN: Absolutely. I'm not sure how the third time happened but I'll take it. CHARLES: Well, this is going to be the second one, we're going to be talking about Redux and then I believe you're on the podcast back in 2014 or 2015. TORAN: That's right. CHARLES: That's one of our first episodes. Make sure to get in touch with our producer afterwards to pick up your commemorative mug and sunglasses to celebrate your third time on the show. Awesome. I'm glad to have you. We actually tend to have people back who are good podcast guests. TORAN: Thank you. CHARLES: Yeah, I'm looking forward to this one. This is actually a continuation of a podcast that we did back in January that was actually one of our more popular episodes. There was a big demand to do a second part of it. That podcast we talked about the ember-redux library, which you're a maintainer and just kind of working with Redux in Ember in general. We're going to continue where we left off with that but obviously, that was what? Almost six months ago? I was wondering maybe you can start there and there been any kind of new developments, exciting things, what's kind of the state of the state or the state of the reducer or the state of the store in ember-redux. TORAN: For ember-redux, in particular, we're working on three initiatives right now. The first is making the store creation more customizable. A lot of people that come from the React background in particular are very used to hand crafting how the stores put the other with the right middleware and enhancers and reducers and that's been fine. I wanted to drop people into the pit of success and everybody's cool with that but now we're getting to a point where there are people wanted to do different things and it's great to open the door for those people if they can, while keeping it very simple so we're working on that. We have here that's just undergoing some discussion. We're also, just as the wider Ember community -- you guys maybe involved in this as well -- and trying to get the entire stack over to Babel 6, the ember-cli Babel 6.10 plus stack. There is a breaking change between Babel 5 and 6 so we're also having some discussions about the ember-redux 3.0 version bump at some point later this year, just because we really can't adopt this without introducing basically a breaking change for older ember-cli users. CHARLES: Just in general, this is a little bit off topic, what does it mean to go from Babel 5 to Babel 6, if I'm an add-on author. TORAN: I would probably ensure that need to speak more with Robert Jackson about this. We just kind went back and forth because I thought I had a Babel compile error. He's like, "No, you're missing this dependency which is the object spread." Unfortunately, the object spread is rampant in React projects and this is totally cool. I had to actually add that and that's just a breaking difference between these two. If we adapt the new version of this in the shims underneath of it as an Ember 2.43 user, if you're on node four which is still supported, you will break without this. I'm trying to get some discussion going about what we should do here and if we even should push ahead and just say only node six is supported. There's some discussion and then back to your original question, the third piece is we've introduced the ability to replace the reducer but we need to get some examples for hot reloading the reducer. That's a separate project but it needs to be enabled by ember-redux. Those are the three main initiatives. CHARLES: Being able to you hot load your reducers, just to make changes to your reducer and you just thunk them into the application without having to lose any of the application state and that one of the reasons that's possible then is because you're reducers have no state themselves. They're just pure functions, right? TORAN: Exactly. CHARLES: Okay. Awesome. That sounds like there's a lot of cool stuff going on. Beyond ember-redux, are there any developments to look for on the horizon in the wider Redux community that might be coming to Ember soon? TORAN: Actually one of them is actually fairly new and it's already in Ember and just because I have already got a shim up for it is redux-offline, which I remember you had Alex on two episodes ago about breaking your brain around Rx. I feel like that happened for me trying to build apps offline first. This is, of course just another library that can drop in that place nicely with Redux but I feel like the community, at least it's got me thinking now about what an absolute that would really disrupt someone who's a big player today. I feel like you've built a great offline experience with true and well done data syncing. You could really step in and wreck someone who's in the space today. CHARLES: Right, so this is a sim around... what was the name of the library again? TORAN: Redux-offline. CHARLES: Okay, so it's just tooling for taking your store and making sure that you can work with your store if you're not actually connected to the network and like persisting your store across sessions? TORAN: Yeah. It uses a library that called redux-persist that takes care of and kind of hydrating the store if you have no network connectivity. But it's also beginning to apply some conventional pattern around how to retry and how to roll back. It's just an interesting look at the offline problem through the lens of an action-based immutable data flow story. It's interesting. I don't have a ton of experience with that kind of tweet and rewrote my Yelp clone with it and that was tough. That's what I mean by this. It's like I thought this is very trivial but you have to do a lot of optimistic rendering and then sort of optimistically gen primary keys that gets swapped out later and it's tricky. If you've never done offline first, which I have not, I just think offline is pretty cool and along those lines, there's been a lot of discussion around convention. There's of course, Create React app which is like a little library or CLI tool to kick off your Redux in React projects. It's kind of ember-cli, very trimmed down version of that right now and that's just getting incrementally better. Of course, you guys are in the React space so you may touch upon that story if you haven't already. CHARLES: All right. We talked to the very high level, I think the last time we had you on the show but now that the idea is gaining traction, kind of delve into more specifics about how you use Redux in Ember. I asked at the end of the last podcast, let's step through a use case like what would deleting an item look like in ember-redux land. Maybe we could pick that up right now and just understand how it all connects together. TORAN: Yeah, absolutely. Without understanding how this entire flow or this event bubbling happens is hard to get your head around it. The process we're going to walk through is exactly that use case you laid out, Charles. We're going to have a button in our component and that button, on-click the idea is to remove an item in a list that we happen to be rendering, let's say. If this is a child component like the very primitive literally button that you have and you just have your on-click equal probably a closure action in Ember, the parent component or the outer context is going to be responsible for providing the implementation details for this closure action and what it does. This is kind of the meat of what you're getting at. The high level here is there is a single method on the Redux store that you have access to and it is called dispatch. The nice thing about Redux again, the API surface area is very small. It's just a very handful of methods you need to get your head around. This one, in particular takes one parameter, this dispatch method. That parameter is a JavaScript object. Now, if you're just playing around, you just want to see the event flow up, there's only one requirement asked of you and that is type property. This JavaScript objects have a type that is often a string so it's very human friendly, you just put in there and the string remove item, let's say. Now of course, if you want to remove a particular item in this remove example, you of course want to pass some information as well beyond the type. The type is mostly just a Redux thing to help us identify it but in this case, you'll definitely know the primary key or the ID value, let's say of the item you want to remove. In addition to type, this JavaScript object, let's just say has an ID property and that can come up from the closure action somehow if you want. Once you click this, what's going to happen is you're going to fire this closure action, the closure action is going to invoke dispatch with the JavaScript object and dispatch is going to run through the reducer which is the very next step and what we do is we take the existing state. Let's say we have a list of three items, that's going to be the first argument now in the reducer. The second argument is this action which is just, as I describe it a JavaScript object with two properties: type and ID. You can imagine an ‘if' statement, conditional switch statement that says, "Is this the remove item action? If it is, okay." We had the ID of the item that want to remove and since we have a dictionary where the primary key of the item is the ID, we can just use lodash-omit and we basically use omit to filter out the ID and then use object assigned to a transform or produce a new state and then a callback occurs after this that tells your list component that somewhere in your Ember tree to re-render, now only showing two items. CHARLES: One of the things I want to point out there, you just touched on it but I think it's an interesting in the subtle point is that the lodash method that you used was omit and that's how this is kind of tangential or I'll say parallel to programming in this way is that you don't actually use methods that mutate any state. You calculate new states based on the old states. I think that's a great example of that -- that omit function -- omission is the way that you delete from something in an immutable fashion. You're actually filtering or you're returning a new copy of that dictionary that just doesn't have that entry. You're just a omitting it. You're not destroying the old one. You're not deleting anything. You're not changing it. You're just kind of Xeroxing it but without that one particular entry, which is ironic because the effect on the UI is that you have done a delete but really what you're doing is omitting there. I just think that's cool. I think it's one of the ways that using the systems teaches you to think about identity differently. Then the question I want to ask you was, this all happens in the reducer, what does that mean? Was that word mean -- reducer? I kind of like danced around that idea and I've tried to understand where that term came from and how it helps give insight into what it's doing and I come up short a lot. Maybe we can try and if we can't explain what the name of reducers, maybe there's some alternate term that we can help come up with to aid people's understanding of what is the responsibility of this thing? TORAN: Yeah, I think we can just break down reduce first then we'll talk about how it ends up looking. But I think it's reduced almost like it's defined in the array context. If I have an array of one, two and three and I invoke the reduce method on that, we actually just produced a single value, sort of flatten it out and produce a single value as the result to that, so three plus two plus one, six is the end result. What we've glossed over this entire time, probably last episode is that this reduce word, I believe is used because in Redux, we don't really just have one massive monolithic reducer for the entire state tree. We instead have many small reducers that are truly combined to do all the work across the tree. In my mind is I think reducer fits well here because we're actually going to combine all these reducers and they're all going to work on some small part of the state tree. But at the end of the day, we still have just one global add-on and that's the output. We want one global add-on with a new transform state and that is the reduced state. CHARLES: You take some set of arguments. One of which is the prior state and you reduce that into a single object. I like that. The other place where I've seen this term applied in a similar context is in Erlang. They talk about reduction so that you have an Erlang server where the way that the servers modeled is as a recursive function call where you pass in the prior state of the server plus any arguments if you're handling a request or something like that, bundled in there is going to be arguments of the request and then what that function returns is a new state, which is then used to pass in to the next state. They call this process reduction. We've got two data points. Maybe there, we can go search for the mathematical foundation of that later -- TORAN: I like it. CHARLES: -- if you want to geek out. I think that helps a lot. Essentially, to sum up the responsibility of the action is you take a set of arguments, it's going to take the existing state of the store, run it through your reducers and then it's going to set the next state of the store or yield the next state of the store. Is that a fair summary of what you would say the responsibility action is? TORAN: Yeah. I think you're right. In fact, in preparation for this talk, I just threw together really small Ember Twiddle that will link in a show notes what I call the mega trimmed down version of ember-redux. It's basically a really naive look but for conceptualizing this flow, it's about 24 lines of code that show exactly what you're saying which is I have this reducer, it's passed into this create store method in the syntax, how do this actually look? It better illustrates how the reducer is used when dispatch is invoked so a dispatch, if I was actually to walk line by line through this, which will be probably pretty terrible. But the very first line of dispatch is to just call the reducer. From that new state transformation, we just push in so the store gets a new entry into it's array of here's the next state and because we had never tampered or side effect-ted the old state, we could easily go back in time just by flipping the pointer in the array or that indexing the array back point. CHARLES: I guess my next question is we've talked a little bit about immutability and we know this reducer that we call at the very first point of the dispatch is a pure function. You were dealing with pure functions, immutable data but at least in perception for our users, our system is going to have a side effect. There's going to be calls to the network. We are, in the least in theory deleting something from that list. How do you go about modeling those side effects inside Redux? TORAN: This is a great intro because in fact a friend of mine is actually a teacher at a boot camp and he was telling me the other day that he was asked to do a brief look at Redux and his very first feeling when he was watching some of the Egghead.io videos is like, "Oh, so the reducer is pure but I have to side effects something so where do I do this?" It's not very clear, I think for the very beginner which is why we left it out of that part one podcast. Today, we're kind of hit that head on but before we get into that list, we can talk about what having actions in their simplest form look like today in your Ember app. As I mentioned earlier in this remove example, you got the button, it just takes the closure action the on-click. No big deal. The bigger work was on the parent contexts or the parent component to provide this action, which sounded very simple but imagine instead of just dispatching synchronously, which is we talked through. Imagine we only wants to dispatch that officially to change it if we have gotten a 204 back and the fetch request is deleted on the server -- normal Ajax or fetch-type flow. In this case, you start to add a little more code and imagine for the moment this is all inline in your component JS file. The component now is started to take on an additional responsibility. In addition to just providing a simple dispatch, as I say, "Go and remove this Mr Reducer later," you're now starting to put some asynchronous logic and as you imagine a real application, you grows and try catch stuff, some error handling, some loading, some modals. This gets out of hand. One of the things that I want to touch on briefly is, at least in the ember-redux case we ship this Promise-based middleware and I want to stop right there for just a second because I use that word 'middleware' and immediately we've got at least highlight what this is doing. In that pipeline -- we talked about earlier -- in the component I dispatch and it just goes right to the reducer. Well, technically there's actually a step or an extension point right before the reducer is involved and that is where middleware comes in. Technically, you could dispatch from this action and then you could handle and do the network IO type request in middleware instead, then porting on another dispatch of a different type with the final arguments to be transformed. That's really the role. CHARLES: Can middleware actually dispatch its own actions? TORAN: Correct, yep. In fact, one of the first big differences between this example as I'm kind of hacking around the component and I've got access to dispatch but there's two things I'm really actually lacking if I don't leverage middleware full on. The first is I do have some state in the component but often, it's actually just a very small slice of state that this component renders. If there's actually a little bit more information I need or actually need to tap into the full store, I don't have it and that might be considered a good constraint for most people. But there are times you imagine more complex apps, you need the store. You might even see a little bit more state, middleware provides that is where you trapped with just that slice of state and dispatch the keyword. That's about it in the component. But the other side effects are the benefit, as you break this out is you get another seam in the application where the component now is not involved with error handling and Promises and async flows or generators. It just does the basic closure action set up and fires dispatch almost synchronously like you did in our very simple example, allowing the middleware to actually step in and play the role of, "Okay, I'm going to do a fetch request and I'm going to use a generator." It's almost like the buffer for IO or asynchronous work that it was missing in our original equation. Imagine, you want to debounce something or you want to log something or you want to cancel a Promise, which you can't do, any of that stuff that's going to happen in this middleware component. That's one of the things I like about middleware as I learn more about it and the moment you get to a very complex async task where you're actually doing the typical type ahead, where you literally want to cancel and not do the JavaScript work or you like to cancel the Promise as quickly as you can, you can very quickly dive into something kind of like what you and Alex talk about with ember-currency in the Redux-land. It's called redux-saga. It's just a generator-based async work. CHARLES: Is saga kind of emerged as async library that everybody uses? I know it's very popular. TORAN: Yeah and a good reason, I mean it solves a lot of the problems that if you were to try and do the cancelation token Promise stuff that came out a while back where we're trying to figure out how to cancel Promises. There's a lot more ceremony and just a lot more state tracking on your own that generators and even when I played with this last week, which is actually redux-observable which is an Rx-based middleware. It's built by, I think Ben Lesh and Jay Phelps from Netflix or... sorry, Jay is still at Netflix but anyway... You could use Rx, you could use generators. This really is just the escape valve for async and complex side effect programming that can't or shouldn't take place in the reducer because it's pure. It shouldn't take place necessarily in a component because one of the best pieces of advice I got when I was younger was, " Toran, make sure you do or delegate," and we're talking really about levels of depth in your methods at the simplest. But it applies here as well, which is I would love it if I had just a very declarative component and I didn't have to get into the weeds as I was looking at it about, is this a Promise? Is this Redux thunk, as they call it? Is this a generator or is it Rx? I don't even care in the component for the most part. I just need to know the name of the action and the arguments. If I'm having a problem with the Rx side of the generator, I'll go into the middleware and work from that particular abstraction but you can see the benefits of the seam there. CHARLES: Are the middlewares match on the action payload in the same way that the reducers do? Is that fair to say? TORAN: That is fair and I will warn. If that seems very strange, you're probably not alone. In fact, the first time I did this with redux-saga, I was dispatching, only to turn around then dispatch again. It feels very strange the first time but again, keeping in mind that you're really trying to have a separation from the work that is side effect and the work that is pure. The first action in that scenario, we'll call it remove-saga because it's actually going to fire something to a middleware. That work is all going to be network-heavy and it's not really as easily undo-redo because it's not pure. But the second event invoked from the actual middleware itself that says, "Remove item. Here's the ID. We're good." That work could be undone-redone all day because it hits the reducer, which is sure you can in and out. CHARLES: It sounds like basically the middleware is allowing you to have a branching flow structure because they all do involve more actions getting dispatched back to the store to record any bookkeeping that needs to happen as part of that. If you want to set some spinner state, that will be an action that gets dispatched. But in terms of sync, they allow you to set up sequences of actions or if you basically have one action that will actually get resolved as ten actions or something like that. If you think about an asynchronous process, you have the action that starts it but that might end up being composed of five different actions, right? Like I want to set the application into some state that knows that I've started my delete and that means I want to show like the spinner. Then at some later point, I might want to show progress like this deletes really taking a long time and I might want to dispatch five different actions indicating each one of those little bits of progress. Then finally, I might want to say it's done or it fails so really those got decomposed into 10 actions or five actions or whatever so the middleware is really where you do that, where you decompose high level actions into smaller actions? Or it's one of the places? Is that a correct understanding? TORAN: Yeah, I think if you're an old school developer for a minute, it will cater to the audience that maybe came from early 2000s backend dev. Now, they're still pretty current in web dev. I see it talked about as business logic. I feel like this is really the bulk of the complex work, especially if you're using Rx. You're actually creating these declarative pipelines for the events to flow through. My components are much thinner by comparison. They're truly just fire off this action with the information to kick the async pipeline but in the async piece of it, there's a lot more work happening and that's I think because there's a lot of complexity in async programming. CHARLES: Right, and it's almost like with the reducers then, there's not so much business logic because you're just resolving the implications of the new state. Is that fair to say? It's like now we've got this information, what does this imply directly? TORAN: Yeah, I think there is this old [inaudible] thing where they're talking about what's should be thick. You know, thick controllers or thick models, what should it be? Of course, we never want 'thick' anything, is the right answer, I think. But the apps on building today, I feel like if any was thick-er -- a measure of degree bigger in effort or work -- it is these middleware components right now. I think the nature of what you describe, which is the reducer is not supposed to be doing anything complex. It's literally taking a piece of data in, producing a new piece of data out. Logically thinking about that takes much less effort, I think than the human brain applies to async programming in JavaScript. CHARLES: Right. I think it makes sense and some of these things are just going to be necessarily gnarly and hairy because that's where the system is coupled. I can't say anything about whether the delete succeeded or failed until I've actually fired off the request. Those are implicitly sequenced. There has to be some glue or some code declaring that those things are sequenced. That has to be specified somewhere, whereas theoretically with your reducers, you could just run them all in parallel, even. If JavaScript supported multithreading, there's absolutely no dependency between those bits of code. TORAN: I think so, yeah. I think there are still some challenges because in the reducer sometimes. We can talk about this in a few minutes but you may actually be changing several top level pieces of the tree. If you're de-normalizing, which is what we probably should touch on next, there are some cases where you want to be a little careful but like you said, generically immutable programming enables multithreading. We're not touching the same piece of state at same time. CHARLES: Right as long as that piece of state that you're touching, like you need to resolve the leaf nodes of the tree first but at any siblings, I guess is what I'm saying on there, ought to be able to be resolved in parallel. It's more an exercise in theory or just a way of thinking about it because like why you're able to do those reducers as kind of these pure functions is because there's no dependency between them. I guess I'm just trying to point out that to wrap my head around, there are places where there are just clear sequences and dependencies and those are things that would be in the middleware. TORAN: Gotcha. I came a little scared of service worker. [Laughter] CHARLES: Actually a great point is what kind is the analogous -- if there is anything analogous -- in Ember today that's fulfilling the role of middleware. What's the migration path? What's the alternative, just trying to explore like where you might be able to use these techniques that we've been describing inside your app? TORAN: I think, at least my look at it has been a service injected into a service, which sounds completely bad or sounds broken the first time you see because you're like, "We're injecting a service into an existing service." I say that because, for me at least there is a top level service that owns the data and provides read-only attributes but there should be some other piece of code -- not the component -- that is doing this asynchronous complex processing, we just talk about as middleware, that is often a different service than the service that owns the state add-on. That's what I meant by service-injected. There's some Ember service whose job is to manage the complexity and probably ended up in middleware from the Redux perspective or ember-concurrency is literally solving that in my opinion. They do a lot for you: solving the async problem generally and I haven't dug into ember-concurrency enough to know. The pipeline stuff, I think which you guys talked about, which is an RFC, that may have eventually be what I consider the Rx or redux-saga of the middleware today. CHARLES: Right. I think ember-concurrency is just absolutely fantastic but it is a hairy problem but there's some overlap in terms of what it is solving. I think that is interesting. I guess a case where you would use middleware would be anywhere that you would use ember-concurrency. I think the interesting thing to compare in contrast there is one of maybe advantages or disadvantages -- let's just call it a tradeoff -- is that with ember-concurrency, you have this middleware that is associated with an object. It's associated usually with a component or a route. When things happen to that component, you're able to affect your ember-concurrency process but it does mean, these things are sprinkles throughout your application and the rules that are governing them can be really different, depending on which part you're operating in or just because sometimes you're using them on a route. Sometimes, you're doing it on a component. Sometimes, you're doing it on a service, whereas with the putting in the middleware, it sounds like they're going to all be in one particular place. All right. Let's move on from the simple to the more complex because that's where it's at. We've talked about modeling async processes, we've talked about handling state transitions and all that, nothing typifies that more profoundly in Ember community than Ember Data as just a foundation for state and syncing it over to the network. Love it or hate it, it's very popular. What are the things that you do in ember-redux land? One, is it fundamentally incompatible with Ember Data or is it just more easily served with other alternatives? How do you handle those foundational interactions, those fun foundational async loading network interactions with Ember Data, just using an ember-redux? TORAN: Yeah, for myself, I don't have an experience actually using the two together on purpose. There is a gentleman who did a talk sometime last year and I'll dig up the YouTube clip for you guys, where he talked about his approach where you would actually produce new states so it's still Redux friendly. Ember Data itself just be a new Ember Data model, every time you transformed it. But one of the tricky points is the philosophy of both so in Ember Data, you're just invoking set on everything and not just how it works. That's how the events bubble through the system as you re-render. You never actually create a new state of the system that's a copy, minus or plus, other attributes. You just always touching a single source of truth. I felt like that was always a sticking point. Anyway, Thomas who did this talk and I'll point you guys to it, did a great job of saying like, "Look, if you're stuck in this world with a lot of Ember Data, you're having some pain points with it and you want to try Redux to see if this alleviates those by not changing the state, here is a middle ground," which he did, I think a fabulous job driving it out. Although I must admit, there's got to be some challenges in there just because of the philosophical difference between the two. CHARLES: Yeah. It definitely sounds like there's some challenges but I'm actually pretty eager to go and watch that, to see what they came up with. If you're using these snapshot states of your Ember objects, would it be possible then to take all of your save, delete records, even query and have them inside of middlewares like have a redux-saga for every single operation you want to take on the Ember Data store. TORAN: The example he showed is basically the best of both worlds. You don't want to ember-mutate so he has a special bit of code to do that. But because the rest of it is vanilla Ember, you could drop in concurrency if you want to do the saga-type generator stuff. But you could also just make your changes as you would otherwise. You use the adapters, you fetch, you save, you delete, whatever you want to do for the most part. It saves a lot on the de-normalized side, which you would have to do manually. You don't write any Ajax code, which you have to do manually on the Redux side. I think there are benefits if someone could get it to work where you're just not changing the state of Ember Data, which may actually just be the future Ember Data at some point as well. CHARLES: It sounds like there is a pathway forward if that's the way that you want to go and the road that you want to walk so we'll look for that in the show notes. But my question then is, you're here on the podcast, what do you do? TORAN: I do want to have one disclaimer here, just so that I'm not a complete poser but I am. If you guys don't know this, I'm not trying to hide this from the community but I don't work on ember-redux at work. I don't have a side gate, making money with it. I don't use it ever. I literally just build examples to try stuff out. There's both a blessing and a curse of that. The curse is that you're asking, "Hey, Toran, you're the author. How does this work, man?" I can give you my run at it which I will but there is the other side which is very clear is that I have not built and shipped Facebook -- the current company I'm with -- with X million people hitting every month. We're not using it. This isn't exactly 'Toran-stamp of approval' here but I do mess around with -- this week in particular -- Rx which I like. I think Rx is just something that it changes the way you think about the way programming, especially async programming works. I definitely cannot comment much on Rx other than I like Alex's challenge to the community on your podcasting. Go use Rx, even if you use ember-concurrency or don't use ember-concurrency, how to break your brain. It will be for the better. Actually, Jay did a mini code review with me because my first pass at Rx was just using the fetch-promise because I was like, "I want Rx for side effect modeling but I wanted to still work with Ember acceptance testing," because I still feel like Ember is leading in that way, as you guys talk about in podcast recently. What was really cool is actually there's a shim that obviously Rx has its own little Ajax thing but it is not actually Promise-based. The advantage of this that Jay called out is in the Promise-based, where I'm using ember-fetch, let's say and I'm just wrapping it with Rx, those Promises are still not really cancel-able so what Jay was warning me about is like, "If you're going to use this quick and dirty, great. but in a real app, these will still queue up in Chrome or IE and block the amount of network requests you can actually make," so don't use Promises, even though they're very familiar. Use this operator, I think it is or a helper inside Rx which is the Ajax non-Promise-based operator. Long story short though, there's a good amount of work involved that grass is greener. In Ember Data, if you've ever used 'belongs-to' or 'has-many', you have done the most magical thing right there. In all the right ways, it is amazing because once you're in Redux and you're like, "I have this very nested object wrap," but Redux isn't meant to operate on this nested object wrap. It's meant to operate on this single tree structure, at these many top level entities as I can. As a project that's pretty popular in React called normalizer, you will likely use this project eventually. Maybe, not your first 'Hello, world', but you'll use this to actually break apart or truly de-normalized the structure. What that does a lot of times is if you have a blog with comments nested all inside of it from your JSON API call or your GraphQL call, that's fine coming from the network. But since you're going to have different components listening for just the comments, maybe or different components that just listen and re-render when the blog name changes and they don't care about the comments, you want to actually de-structure that so you have a separate blog top level item and you have a separate comments top level item. They're still related so the blog can get through its comments and vice versa as belongs-to and has-many works in Ember Data but you've got to do that work now. There is, of course magical projects like redux-orm that I just can't speak to how well they work or don't work but they try and solve the more Ember Data, look at the problem which has define this and there's the RM take care of the magic for you. I actually don't mind normalizer. It's just something people should be aware of because it's more work. You've got to break that apart yourself, just as much as writing your own network requests. You're, hopefully not going to duplicate Ajax all over the place but you will have to do the work that you otherwise do not do in Ember Data for sure. CHARLES: It's very interesting. If you look at the Ember Data internals, it sounds like the Ember Data store is actually structured very similarly to the way you had structure a Redux store using something like normalizer where you have these top level collections and then some mechanism to both declare and then compute the relationships between these collections of top level objects. But I want to go back to your other point too. I just wanted to say this. Toran, you know, don't sell yourself short because you give an incredible amount of time, an incredible amount of support to the community. You're very active in the Ember Redux channel. When problems come up, you think about them, you fix them. Even if you're not actually watering the trees, you're planting the seeds. I think that's actually great. I think that is a very valuable and necessary role in any community is to have people who are essentially the Johnny Appleseed of a particular technology. I think you go around and you throw these seeds around and see where they take root, even if you're not there. You're on to the next shady lane to plant seeds, rather than stay and enjoy the shade and the fruit of the apple trees. TORAN: Yeah. I appreciate your kind words there because a couple of years ago, I got into open source because it provides good personal branding. It's like, "This project, it's Toran's. We should hire Toran." It just makes you look more from that perspective. It also gives you almost a way to skip out on tough interviews at times if people are like, "This guy have a decent program. Let's take a look at his PR. He communicates with other humans online." It gets rid of some of that. But there is a dark side. We don't talk about it because there is an upside to it, especially for consulting but the dark side can be time commitment: how much bandwidth do you have outside of your family life, your hobby, if you have one and any other open source or work-related stuff that you already have to do. For me, this is really an exercise in thought leader-y stuff. I saw the benefits of this. It made my Ember better. Even if I wasn't using Redux, it just made the Ember code I wrote at work better. It inspired me to look at different things like ember-concurrency and Rx, things that are just way out of my comfort zone two years ago. I think those are all the benefits that come with it but the easiest part is got to be some value from it. The juice is it worth the squeeze. I think the community we've built and the people using it and the problems we're solving are all definitely worth the squeeze. CHARLES: It definitely is and you can tell from the vibrancy of that community that a lot of people are experiencing that value from it. To your point, I think something that is often lost on people is that you can actually use a project without actually using it. I think that there might be many people, for example in the Ember community that have never use React but are actually in fact using it because of the wonderful patterns that have come out and it's brought to the fore. I had thought about immutability, certainly on the server side but I had thought about it really deeply on the client side until a library like React came along and people started talking about it. I would say before we actually started using React the library, we were using it in thought. You touched on that when you were saying, "It's changed the way I think, it's changed the way I code." Even it's changed the way that I do things at work, in fact you're using it in spirit, if not the actual structure but I almost feel like that's more important. It's longer-lasting and has a greater impact on you, 10 years down the road or even five years down the road when neither of the technologies that we're actually talking about today are even going to be in wide use. TORAN: Yeah, that's true. In fact the one thing I would call out that people check out, I think Alex mentioned this or at least you guys have to talked about it in passing but definitely, sometime this weekend, watch the Simple Made Easy talk by Rich Hickey. It will definitely make you think differently, regardless of the simple side or the easy side that you follow on, projects of course make tradeoffs both sides of that but it is a great talk. Especially, if someone who's been programming six months or a year or two years, they're going to get huge benefit from it, just as much as someone older like myself who has got 10 plus years in the biz. CHARLES: Yeah, I know. That is a fantastic talk. We need to link to it at every single show. TORAN: Exactly. CHARLES: Well, I think that is a fantastic note to end on so we will wrap it up. That's it from Frontside for this week. We're going to have you back, obviously Toran there's so much that we could cover. Six months down the road, we'll do part three but for now, that's it. Thank you, Wil. Thank you, Toran for podcasting with us this morning. TORAN: Thanks for having me on guys. I really appreciate it. CHARLES: Then everybody else, take it easy and we'll see you all next week.

Alex Matchneer: @machty | FutureProof Retail Show Notes: 01:07 - The Introduction of ember-concurrency 02:15 - What is ember-concurrency? What are the problems it solves? 05:37 - Why not use observables or other alternatives? 09:49 - Could observables be used in conjunction with ember-concurrency? 12:16 - Simple Made Easy 14:23 - Coming Soon to ember-concurrency 16:04 - Communicating Changes in State; Glimmer Reference Primitives 23:09 - Using References 29:31 - Submitting RFCs; Adding Pipelines 32:10 - Pipeline Use Cases Resources: ember-concurrency The Frontside Podcast Episode 007: The Ember Router with Alex Matchneer The Frontside Podcast Episode 019: Origin Stories with Tom Dale and Alex Matchneer Introduction to ember-concurrency by Alex Matchneer from Global Ember Meetup RxJS Rich Hickey: Simple Made Easy Glimmer.js redux-saga Lauren Tan's RFC: Cancellable task pipelines Railway Oriented Programming Apache Kafka Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 67. My name is Charles Lowell, a developer here at The Frontside and podcast host-in-training. With me today also is Elrick Ryan, a developer here at The Frontside. Hello, Elrick. ELRICK: Hey, what's going on, Charles. CHARLES: Now, we have with us today someone who we love to have on the show. Everybody probably already know him. I know the first time I actually heard about him was when we had him on the podcast the first time, I was like, "Who the hell is this guy?" But since then, he's become one of my favorite developers, just with all of the things that he's done, from Router.js to more recently ember-concurrency. We have Alex Matchneer on the program. ALEX: Hey, everybody. Thanks for having me. CHARLES: Hey, Alex and you know what? I pronounced your name right this time. First time out of the gate. Boom! ALEX: Nice. Which one did you go with? Matchnear? Matchner? [Laughter] ALEX: I really actually don't even know which ones correct anymore. CHARLES: Was it about a year ago that you first introduced ember-concurrency? ALEX: Yeah, I had a really embarrassing introduction of it at an Ember Meetup in January before it was really done and I just kind of botched it and didn't really introduce why it was even solving problems. Then a month later, I had some time to refine it, driven by the feel of that embarrassment. I guess around February of last year, it's been pretty much in its present state. CHARLES: I remember when it came out. I must've seen the non-botched version because I remember hitting the ground running with it and being able to refactor all of this code. I definitely know that I got the honed version because you provided in that initial blog post a whole host of examples like what are the symptoms, what are the cases where it solves and then before presenting the solution. I think that was great because I didn't even realize that I had a lot of pain. I didn't realize that at all. I didn't realize I had a problem but then you were very, very elegantly packaged the problem with the solution which is always great because otherwise, it's just complaining. Maybe we should talk a little bit about -- I don't think we've officially talked about -- ember-concurrency. Even though it's been out for quite a while, the way that you model these concurrent processes using the stack is just pretty incredible. Do you want to just very briefly touch on what the problem is and what have lead you to this solution? ALEX: Sure. It's a little bit difficult to sort of succinctly say what ember-concurrency is because it kind of hits them like five different separate but kind of related but not really pain points. At its core, it's just like a task primitive and it's definitely not the first library to ever introduce that the JavaScript, I think particularly when the generator function syntax was introduced into the spec, I think a few years back. Dave Herman who's also known as, I think a Little Calculist. I think he works on the TC39. I always get those groups a little confused in my head but he introduced a task.js library that let you use the generator function syntax and then lets you yield Promises to sort of pause where you were in that task and then continue when it resolved. It had some support for cancellation. It played well with Promises and I brought that to Ember in a way that fit really nicely with Ember more than it probably does or will with other frameworks like React or Vue. By bringing it to Ember, basically if you're implementing any feature that involves async, if it's a button that needs to show that it's been clicked while you're waiting for some response to come back from the server, instead of using Promises, instead of using actions, here's an ember-concurrency task. It makes it easier to express that operation you're trying to do and it makes it really easy to drive your UI with state that comes from the state of that operation -- Is the test still running? Is your form still submitting? -- Rather than having to manage a bunch of mutable flags and properties on a component or state yourself and likely get it wrong. CHARLES: Right. Essentially asynchronous processes is like a state machine and before, we were kind of managing that state machine by hand but I think what's so brilliant about this task-oriented programming, I guess is maybe a way to put it because I really think that some of these ideas are universal and not specific to ember-concurrency. But it almost like it uses the stack, just your normal programming stack to track where you are inside of a process, rather than what it felt like what we were doing before, which was managing this state machine by hand, if that makes any sense. ALEX: It does make sense a lot of sense. A lot of people ask me, if you're going to go into sort of async territory, why aren't you using something like RxJS? Rx is observables and kind of popularized by the Netflix crowd who did a bunch of presentations on them. It's super popular these days. But one of the things I really like about RxJS or at least one of the realizations I had is that I think you're still building a state machine. You're just expressing it using different primitives. In Rx, you're still building a state machine but in Rx, they make you think about it in terms of streams and events firing over time. In ember-concurrency, also you're still building a state machine but you're using the generator function syntax and the call stack like you mentioned as another way of expressing that state machine but with a lot less code. CHARLES: Right. I was actually talking to someone about ember-concurrency just a few days ago and they were saying the same thing, "Why not use observables," and at least from my perspective, maybe I didn't quite understand the question because I feel like observables are kind of only one of the concerns that ember-concurrency addresses. I'm curious when people talk about alternatives to ember-concurrency and put observables forward, maybe I don't understand it because I usually think you might be able to use observables to register the currently executing task state and every time it changes, emit a new state and is then observed by your observable subscribers. But modeling the actual process using observables does seem weird to me because with observables, they seem like very purely functional and not heavily stateful. I don't really have that much experience with it. What's meant by using observables as an alternative? Maybe we can get more into those like how you would construct a stream or something like that? ALEX: I think the canonical Rx example of something that's elegantly expressed in Rx that would be really hard to do in just normal JavaScript, if you weren't able to use observables, is that typeahead search where as you type characters into a text field, it's already beginning to hit the server and see what you might be searching for so it can drive the state of some drop down menu. That's probably the most popular example out there because one of the things it demonstrates is that if you want to debounce, you want to allow for the user to stop typing for like 200 milliseconds before it actually hits the servers so you don't overwhelm your server, then just add a debounce operator. You've basically transformed a stream of keyboard events into that text field into something that only kicks off after it hasn't gotten an event for 200 milliseconds. If you already had a working prototype in vanilla JS and you had to debounce it, you've got to move a bunch of stuff around, you've got extract something into a function, you've got to deal with cancellation. But all those things are kind of pretty elegantly built into Rx and if you can train yourself to think in terms of streams of events, that inspires you to think about where else you could apply that in your app. I think a lot of people have felt that it's like winning, most powerful abstraction that you could think about. That's why things like cycle.js are a thing or redux-observable or just anybody working with observables in the Netflix territory. I personally find [inaudible]. If you're going to express certain processes, Rx is the way to go but it has drawbacks which is it is really hard to learn. It took me a very long time and I'm pretty good at it but if you're going to adopt Rx in your code base, then a new developer comes on, it's going to be a pretty long time. In my experience, sharing some of the Rx code I've written with fellow very talented developer, it takes a really long time to explain how to invert your thinking and think of things in terms of events. If you can get to that point, more power to you but what I found with ember-concurrency stuff is you don't have to completely invert your thinking and think of everything in terms of events and streams of events. You can use this task primitive which feels really pretty close to the code you're already writing but gives you a lot of the safety guarantees and just makes it really easy to use this derived state to drive templates. Rx is a powerful paradigm and sometimes you need that sort of event-driven push based model but I think when people wonder why aren't you just using observables, they haven't really grasped how easy and familiar it is to use task and get it right on the first try and with a lot less code. CHARLES: Right. You're able to leverage the fact that I understand what a JavaScript function looks like and the sequencing is implicit by just the order in which you were numerate the steps, right? ALEX: Right. Because I think that Rich Hickey of Clojure popularized the divide between simple versus easy and Simple Made Easy is one of his popular talks that everyone should probably -- CHARLES: It's a great talk. Yeah. ELRICK: Do you see an area where observables could be used in conjunction with ember-concurrency? ALEX: It's kind of. It's been hard for me to find that use case. Probably, there's a handful of use cases where maybe it's a little awkward to think about to have something that would be elegantly handled in Rx would be model using tasks but it really hasn't struck me enough in some of the apps that I'm building, to really try and flesh that out. CHARLES: I would be curious to see a side by side comparisons. I build a lot of auto completes using ember-concurrency. I built a lot of asynchronous processes using ember-concurrency. What would that look like using nothing but Rx and just be able to have it on the left-hand side of the paper, then Rx on the right hand side of the paper are easy. ALEX: I'd be very surprised if you could find an Rx example that is less code than the task equivalent because as much as I think the autocomplete example is the best canonical example of Rx, once you actually start making something that's production-ready, you want to start driving the button state while it's running or to show a loading indicator. When you start deriving other observables off of the source observable which is the user typing into the text field, you start having to worry about, "I'm dealing with a cold observable. If I create another stream based on it, it might double subscribe and I might kick off two things. I actually want to use a published.ref version of the stuff." To actually get away from a toy example into something that's actually production-ready, requires a lot of code. From my own conversations with the people working on Rx, there's a lot of people that are working on it and they're pragmatic about it and don't think that you have to be just purist functional all the way. But when they actually ship production code, they usually resort to using like the do operator. With Rx observables, which is basically an escape hatch to let you do mutations and side effects in what is supposed to be this monadic functional thing. If the paradigm is breaking that quickly to do production code, I'd wonder if maybe there is something better out there. I just kind of keep that in mind but I'd definitely think there should be a bake-off or comparison of how you do things in both the task paradigm and observable paradigm but I think you'd find that in most cases, just do a lot more with a task, with a lot less code. CHARLES: I want to go back to the point you were about to make about Simple Made Easy. ALEX: On the divide, ember-concurrency is very easy. I still choose easy. In the case of reservable, I'm constantly choosing easy over simple and then it always helps me out because I've made that decision. I think most people inspired by Rich Hickey from the Clojure community, would look at ember-concurrency and be like, "At a task that combines derive state and does five different things seems kind of gross. Why don't you just use observables," and the result of that if you follow it through is that you end up writing a bunch of observable code that is a mess in streams and going in different directions and you've written something that's really hard to understand, even if it's seasons Rx developers looking at the code. It's just very easy to write things that are tangled. CHARLES: It's always good to have simplicity but also a system that simple without ease, I think is far less useful because like I said, it's always going to be a tradeoff between simple and easy but the problem is if your system is too simple, then it means that you're shouldering your day-to-day programming task or shouldering the complexity and you have this emergent complexity that you just can't shake because your primitives are just too simple. You could be programming in assembly language or something like that. That's really simple. You need to be able to construct simple primitives on top of simple primitives so for your immediate need, you have something that is both simple and easy, if that's ever possible. Certainly, ember-concurrency is easy and I think it just means there's maybe work to do in trying to tease apart the different concerns because like you said, there are five. But in real complex systems, there are five bajillions, maybe teasing apart those individual concerns that is composed out of simple primitives. I'm sure you've thought about that a little bit of how do I separate this and make these tasks compose a little bit better and things like that. ALEX: This is a nice segue because it might tie into some of the work that's going to be going into ember-concurrency in the next few months. A big theme of EmberConf is actually, a lot of people are joking that it should just be called GlimmerConf because a lot of it was talking about how Glimmer is going to be this composable subset of Ember, like Glimmer is going to be the rendering layer and then there might be a Glimmer router and a bunch of these Glimmer components that once you npm install them, you get Ember. Glimmers is a chance to think about Ember as a bunch of components working together under a really nice rendering layer. There's definitely some interest in bringing ember-concurrency in thinking what is so-called Glimmer-concurrency going to look like. Part of thinking about that is going to mean teasing apart some of these details as you were just saying. I don't have a lot of specifics to give right now, just that there is a lot of interest in making sure at the very early on, there is some sort of Glimmer-concurrency equivalent. Generally speaking, as part of that process is the question of how do we bring these magical ember-concurrency parameters to just Node or just vanilla JavaScript in general. Perhaps you could use these kinds of tasks on a server and in other environments. I think there's some questions of the way the ember-concurrency bundles together derived state with the actual tasks runner, are you actually going to use that derived state in the server setting? I think some of these pieces are going to have to come apart a little bit. I don't have very concrete ideas for how that's all going to look in the end. Just that I have faith that it will happen pretty easily and the result of it is going to be something that fits pretty nicely into Glimmer as well. CHARLES: Yeah, I hope so. It certainly seems like one of the core issues right because Glimmer-concurrency really should be universal. It should be some -- I don't want to prescribe your work for you -- ALEX: I don't mind. CHARLES: That wouldn't be cool. I mean, Glimmer is very stripped down. You have a very little bit on top of a raw JavaScript environment so if you're going to go there, it'll makes sense. What is this concurrent process builder look like using nothing but JavaScript? It seems like one of the hardest problems is to disentangle it from Ember object because the way that it currently computes that derive state is very intertwined with Ember object. You know the details of this more than I do but it seems like that's one of the biggest challenges is how do you communicate those changes in state without using that? That what I was thinking, it would be a good case for using observable for ember-concurrency, although not for probably the reason that people are thinking, which is for task composition and stuff but I'm very curious. ALEX: Likely the first stab at that direction would probably be using something similar, if not exactly these Glimmer reference primitives. Maybe it is worth talking about that. References are one of the core primitives that's used by Glimmer and it represents a value that might change over time and it's a value that can be lazily gotten, whereas observables, you have something that's firing events every time something changes and it makes the whole pipeline process it right then and there. With references, when something changes, you just tell the world like something's dirty. Then at a later time, maybe when in a request animation frame or some point where it actually makes sense to get the latest values, then it goes through and finds out everything that changes, does a single rerender. What it means is that you don't have the observe recode that's firing every time some value has changed. It's one of the guiding abstractions in Glimmer that makes it possible for it to be so fast and performant. It is very likely that a vanilla version of what ember-concurrency does uses references because those are already separate from the Ember object model and actually are used today in conjunction with Ember object model with the Glimmer that works with Ember today. I think that's probably, to me a first step. Clearly the reference attraction has worked wonders for Glimmer. I prefer to probably use that than observables and the push-based. CHARLES: Observables or something else. That is really, really interesting because there's nothing like vanilla JavaScript programming these days, like the equivalent of a Haskell thunk where you're just passing these things around but you're not actually using them until you actually want to pull a value. At that point, you kick off the whole chain of computation required to get that one value that you need. But it immediately brings to mind and I don't know if this is of concern to you but I was very, very enamored of Ember objects back in the day, in 2012. I was like, "Wow, this is amazing. This solves every problem that I've had." It has been a great companion and I've built some really great stuff on top of it. But now it's definitely turned into baggage. I think it's baggage for libraries that I've written and we're talking about it in the context of it being baggage here and being making it more available to the JavaScript community so I worry a little bit about Glimmer references. Would they possibly turn into something like that and could you counteract that by maybe trying to evangelize them to the wider JavaScript community like, "Here's a new reactive primitive," so that we don't end up in an eddy of the JavaScript community, do you think there's value in trying to say, "There should be some standard in the same way of observable, which is an emerging standard is for eager reactivity, have some lazy reactivity standard," or maybe it's too early for that. That might be a way of future-proofing or getting insurance for the future so you can say, "We can confidently build systems on top of this primitive." ALEX: If the worry is something based on Glimmer reference as it's going to turn into the same baggage or [inaudible] or whatever, that maybe Ember object has turned into some apps, some applications, some libraries. I'm not sure. I guess I don't really see that happening and I know that it's already gotten some validation from some of the people that have worked on Rx. In fact, a very useful primitives for certain kinds of workloads. As much as evangelism certainly helps. It's already off to a much better start than this all-powerful, god object that you can only interact with if you're using .get and .set functions. It's very lightweight. What I'm trying to say here is that there's UI workloads and then there's server-driven workloads and using Rx for both cases means that Rx suffers as a library because in the UI workload, you want something like references where you want to let a bunch of things change and then update stuff in one pass just a tick later or later in the micro task queue. But in Rx, they make you think about things in event-driven way, which might make sense for servers and stream processing but it's ugly when you want to actually build UIs with it. I think if we pay due respect to the fact these workloads are pretty different, I think the reference is way better of an abstraction for things that are UI-centric. They're simple and their performant and I think it's often much better foot than Ember object which is kind of bloated and huge and very hard to optimize. CHARLES: Right. I like that because you have to be precise with the server side things but ironically, with the references, you only care about the state at the point at which you observe it -- when the user observes it, not when the code observes it. The user observes stuff with every animation frame and there can be any number of intermediate states that you can just throw away and you don't care about. You don't need to compute them. I think what you're saying is Rx forces you to compute them. ALEX: Right and you wouldn't use a Glimmer reference for something if you're trying to batch. But in the end, keep all of the events that were fired on all the change events. You wouldn't use references because you're losing all that information until you do that poll and you get the latest value. But 99% of the time, when you're building UIs, that's what you want to use. CHARLES: Are Glimmer reference is their own standalone library or do they currently bundled with Glimmer? ALEX: I'm not sure. If they are not now, I believe the intention is for them to be at their separate repo. I was talking to Kris Selden at EmberConf and I got the impression that the intent, it might not be there now and if I want to start extracting ember-concurrency stuff into vanilla JS, I'd probably want to use a reference-ish thing, if not the official one from Glimmer. CHARLES: I know we talked about this so then, how will you able to use these lazy references to compute tasks state? How that might work or play out? ALEX: The fundamental problem right now is that everything in ember-concurrency is so glued to the Ember object model. What that means is that all ember-concurrency has to do is broadcast so the changes has happened to the state of a certain task so that you can, maybe put a loading spinner up on your template. All it has to do is use object.set and then the built in computed property observer change detection that is in Ember object model. It's going to sort of propagate these changes but that's a bunch of heavy Ember stuff that is going to exist and a lighter weight Glimmer or vanilla JS context. Instead of using .sets and expecting that the thing you're setting it on is a big, heavy Ember object model, you could just use references. Then whoever wants to get a reference to whether a task is running or not, it is running reference. Then just using the standard Glimmer abstractions. At the Glimmer-concurrency task runner, it would just basically kick those references and anyone who has one of those references can flush and get the latest value at some later point in time and then update the UI based on that. Already, as a maintainer at ember-concurrency, I see all the pieces work with that and I could probably just start working on that today. But there's just a handful of other things that I want to align with the vision of Glimmer and Glimmer-concurrency before I start working on that. ELRICK: What would be the referency equivalent in just plain JavaScript outside of Glimmer that you would use to build this on top of --? CHARLES: Like what would the API look like? If you're like, "I don't have a Glimmer. I don't have anything. I'm just --?" ELRICK: Yeah, you just have plain JavaScript. What would be the primitive that you will build this on top of? ALEX: Whether we use a standalone Glimmer references library or this separate reference thing, then I would use the term based on something Kris Selden said. In the end, the APIs is going to be pretty similar between those two but if one thing is requires, as far as I understand it, you've got to set up where in an event loop, your response is something that's changed and then you schedule at a later request animation frame, to actually do the rendering based on that. In order to use something like references, it implies that you've got to flush at a later tick or flush at a later call back. If you've got that in whatever app you're working on, it should be pretty easy to figure out where references fit in. CHARLES: I see, so you would basically say like new task, give it your task class or whatever -- I'm just making stuff up -- then you would just schedule, do a request animation frame and then just pull the task state or something like that? Or a new task reference or something like that? ALEX: You might have some function that's schedule render pass, if not yet scheduled. Then if it hasn't been scheduled, then use requests animation frame. If you call that function again, it's going to no op until that requests animation frame happened. CHARLES: Could you explain that again? ALEX: Sure. If you're actually thinking of a really low level vanilla JavaScript to your app, in the browser or something and you were just using references, then you probably have something where the thing that kicks off the reference or dirties the reference in some way, also run some function called 'schedule rerender', if one hasn't already been scheduled or something less verbose. That would just make sure that some request animation frame has been scheduled. When it flushes, then it will get all the changes but if more references are dirty at that mean time, it won't schedule additional request animation frames. I don't know, that's kind of blue-skying but that's when -- CHARLES: Right. Here's the other things, you see like being able to integrated with a third-party state management solution like Redux or something. Basically, I've got my ember-concurrency tasks and their state is then reflected inside a Redux store. How might that work, if at all? Or was that a crazy idea? ALEX: I don't know. I played around with Redux toy examples and Redux community and Ember is only stronger by the day. I'm not entirely sure how all those pieces fit together because in Redux, they really want you to propagate all of your state changes using the reducer in that single global atom. A lot of people asked me about redux-sagas, which is another generator function-driven way of firing these state mutating actions over some async operation and this is hugely popular but I don't think they have any concept of the derived state that I've been trying to do with ember-concurrency of just being able to ask a task if it's running. You can't just do that. You've got to reflect that into the global atom -- the global store --somehow and to be honest, I don't really know if that's fundamentally at odds with the Redux model, to take something like Ember or Glimmer-concurrency and make it work that way. But ideally, you wouldn't have to forward all that state into the global atom. You just be able to reference that task object. CHARLES: If the task object itself is immutable, it would have seemed like fairly trivial, like you could generate programmatically the reducer required to do that. If you had the state encapsulated, you could come and say, "Now, there's a new state here." It seems like you would be able to adapt that but you would need to be able to react to any time if that state changed to fire and action in the Redux store or fire the Redux action. ALEX: Actually, this will be an easier question to answer because in the Ember community Slack, there's a Redux channel and I know everyone there is already starting to talk about how are references, how is Glimmer is going to, how can we kind of tie these things to Redux and I think when they have some solutions lined up, a lot of the stuff that will be in so-called glimmer-concurrency will just fit in nicely. If they've got nice models for tying references to the state atom, if you will, then it's going to work with the new way. CHARLES: Okay, cool. One of the things that I wanted to talk about was a proposal that Lauren Tan, who put on to the ember-concurrency issues list, although it's an RFC. Are you accepting RFCs now for ember-concurrency? ALEX: I'm not pompous enough to have a separate RFCs repo. Issue approaches perfectly humble for me. CHARLES: But is this the first RFC or have there been a bunch of ember-concurrency RFCs? ALEX: There's been a few. It's definitely great that Ember have standardize on this boilerplate RFC model that everyone can fit their proposal into because it means that all the add-ons that people really like and really want to invest in, they get these high-quality RFCs versus like, "Hey man. It kind of nice if you can just like, have a pipeline." [Laughter] ALEX: Just because Ember invested in that process, the whole add-on community benefits from it and it's great. There's been a few RFCs that are like that. I'm not sure how many of them have made it but I've seen a few that are in that format but this one's definitely one of the nicer ones and a lot of effort was put into it and it looks really nice. ELRICK: I'm not familiar with the RFC. What was the brief overview of what was proposed? ALEX: Lauren was basically proposing that we add concept of pipelines, which is if you have a series of tasks that are stepping the pipeline of operations, then we should standardize that and then define all the steps in the pipeline so rather than having each step in the pipeline, call the next step in the pipeline. They just return some their portion of that work and then the pipeline infrastructure will automatically run the next step in that pipeline. CHARLES: It seems like also then you can derive state about the entire pipeline, rather than just the individual task. You have to manage that a little bit by hand. But the other thing, I guess I would add is it seems like if you're going to go with pipelines, rather than being a simple list, you might want to think about it as being a tree because can you have pipelines that are composed of sub-pipelines, so to speak? ALEX: Yeah. I believe the answer is yes. I'm not sure if it's spelled out in this RFC but really a pipeline just fits the task interface so if there's a task-ish thing or taskable object that you declare as a step of a pipeline or sub-pipeline, it should just work. I'm not sure if there's more work that needs to be done in spelling that out but that seems baked into it. There's a lot of due consideration for making sure these things compose really well and it's already in a really good state. CHARLES: Yeah. What are some of the use cases where you might want to use a pipeline? I'm sure, everyone who's been writing concurrent tasks has probably been maintaining their own pipeline so what is it that you're doing and how is this going to save your time and money? ALEX: Let's use the example that I've actually used in EmberConf, which is something based on my own app, which is in my app, you have to geolocate and find nearby stores that you could walk into and that process is four async steps in a row. One is getting your geolocation coordinates and then the next step is passing those the store, getting values and the third step is maybe some additional validation or just setting a timer so that your animations or any of these little async things that you have to do. But it's really a sequential operation where each time, fetch your geolocation or get it out of a cache and then step to the next thing, then the next thing. It looks okay as I have it in my production app code but it still feels a little gross that you can just look at this thing and be like, "What is the sequence of steps here?" You have to actually get the implementation of each task to see what happens next and where will it go after that. Basically, with ember-concurrency in general, there's a lot of opportunities for finding more conventions for building apps. I don't even know if we really talk about this so far but derived state is part of it. But generally speaking before ember-concurrency, there wasn't as much opportunity, I guess for some of these conventions for building these pretty standard UI flows without feeling that you're just building your own thing every single time, with chains of Promises and your own improvise cancellation scheme and all these things. I see pipelines as a next step. Well, we're pre-building lots of pipelines in our apps. We have these processes that go through these multiple steps and right now, the best we can do is set a bunch of Boolean variables and the derived state that comes with ember-concurrency helps but with pipelines, there's even more and it also structures your thinking so that if something like pipelines catches on, hopefully as an Ember developer, you'll see them in a few different places and already have that tool in how to visualize a problem, visualize a component, visualize the async flow. CHARLES: If I spent my entire morning reading the talk that Lauren referenced in RFC, which was the Railway Oriented Programming, which I think, maybe not quite but basically a visual explanation of a Maybe monad or the Either monad or whatever it's called. One of the greatest explanations of why monads are helpful and through explanation using like the Maybe, where you can have a computation that could have more than one result, either success or failure and how do I take these functions and compose them with functions that might always succeed or might not have a return value or whatever and show the tracks that move through a computation and be able to normalize every function to have the same number of tracks. I realized, I'm getting into the description of it without actually having the visuals in front of it so I'm just going to stop myself and say everybody go read it. It'll take you 35 minutes but it will eliminate so much like the chatter that you've been hearing in the background for a couple years. ALEX: I used to tell people that they should learn Rx because regardless of me liking the task primitive a little bit better, it's great. It just scrambles your brain and reorganize your thought processes and it's such an interesting library to learn. CHARLES: All right. I like it. I'm going to go learn Rx. ALEX: I've been getting, on the server side, the sort of Kafka-based architecture, Apache Kafka. Particularly, they've released some libraries in maybe the last year or so. It's a very Rx-familiar feeling library for composing new data and new aggregates and joins between different topics and streams of events. It just seems like they're at the forefront of solving these really hard problems in a very conventional way. You get into some of that stuff and you'll find that you're doing a lot of server side processing with step that just feels a lot like Rx and I find it very interesting. I haven't actually build anything with it yet but it is likely in my future and anybody that's into the event-driven model should definitely know what people are working on in this Kafka-streams world. CHARLES: That is cool. It's so interesting to see how all the problems that you encounter on working on the server side, you will encounter on the client and vice versa. You can build up a huge corpus of knowledge on one side of the API divide and you'd be surprised that if you were to go work on the other side for a time, you'll be able to leverage 99% of that knowledge. That's fantastic. I would love to get into Kafka but unfortunately, I think we're going to have to save that for another time. That's another one of those words like... I don't know. Is Kafka descended from Storm or something like that? Is it a similar concept? I remember everybody was big on Storm. ALEX: I think Storm process the events and decides what to do with them. Kafka is really just a giant storage that plugs into something, I think like Storm or [inaudible] or any of these things that actually process the events. CHARLES: Yeah, it's all Kubernetes to me. ALEX: Yeah. CHARLES: All righty. Well, with that, I think we'll wrap it up. Thank you so much, Alex for coming to talk to us. It's always enlightening. I love your approach to programming. I love how deeply you think about problems and how humble you are in approaching them because they are big. ALEX: Well, thank you. It's great to be on here. It's fun. CHARLES: All right, everybody. Take care. Bye Elrick, bye Alex.

Simple Made Easy by Rich Hickey “Rich Hickey emphasizes simplicity's virtues over easiness', showing that while many choose easiness they may end up with complexity, and the better way is to choose easiness along the simplicity path.” Talk Transcript, with slides Fatal Error episode 7: The Single Responsibility Principle Fatal Error episode 15: Not Invented Here Some examples we mention: Object-Relational Mapping vs Key-value Database CocoaPods vs. Carthage Slides mentioned in this post: Development Speed Simplicity Made Easy

We discuss complexity and progressive disclosure, garbage collection, and the impenetrable nature of Git. Chris Lattner on Accidental Tech Podcase Simple Made Easy Garbage Collection was a feature of Objective-C 2.0 The listen gem breaks my laptop Go GC: Prioritizing low latency and simplicity Modern Garbage Collection which calls out the tradeoffs of Go's approach WebKit's Retreating Wavefront Concurrent Garbage Collector The Joel Test Tig: text-mode interface for Git Thank you to our sponsor this week, FreshBooks!

Rich Hickey — Simple Made Easy // http://bit.ly/TAOP128sme Rich Hickey — Simple Made Easy // http://bit.ly/TAOP128smep Легкость вместо простоты // http://bit.ly/TAOP128smet http://riemann.io/ Благодарности патронам: Sergey Kiselev, Sergii Zhuk, Aleksandr Kiriushin, Nikolay Ushmodin, Pavel Drobushevich, Pavel Sitnikov, Bogdan Storozhuk, B7W, Лагуновский Иван, Sergey Vinyarsky, Yakov Krainov Поддержи подкаст http://bit.ly/TAOPpatron Новые темы http://bit.ly/TAOPgit Подпишись в iTunes http://bit.ly/TAOPiTunes Подпишись без iTunes http://bit.ly/TAOPrss Скачай подкаст http://bit.ly/TAOP128mp3 Старые выпуски http://bit.ly/oldtaop

What happens when your database is part of your application? Kenneth & Len are joined once again by Robert Stuttaford from Cognician to talk about Datomic. According to the Datomic website, Datomic is a distributed database designed to enable scalable, flexible and intelligent applications, running on next-generation cloud architectures. Robert shares with us how Datomic became a natural choice for them after switch to Clojure. Before Clojure, ClojureScript and Datomic their site was written in PHP and backed by MySQL. Choosing Datomic was very natural since they've already subscribed to Rich Hickey's "simple vs easy" mindset. Its immutable nature is a great fit for Clojure, and by following an "append-only" storage model they got loads of benefits. We discuss a wide variety of concepts, including how Datomic models data, the different ways it can be stored, how transactions work, the ability to travel back in time to see what your data looked like, and so much more. We were happy to learn that Datomic is accessible to everyone on the JVM, so learning Clojure isn't an initial requirement, but learning some Clojure will go a long way in informing your usage of Datomic. We would encourage everyone to experiment with Datomic and enjoy this different, flexible approach to modeling data. Follow Robert online: - https://twitter.com/RobStuttaford - http://www.stuttaford.me/ - http://www.cognician.com/ Here are some resources mentioned during the show: * Datomic - http://www.datomic.com/ * Datalog - https://en.wikipedia.org/wiki/Datalog * Logic programming - https://en.wikipedia.org/wiki/Logic_programming * Simple Made Easy by Rich Hickey - http://www.infoq.com/presentations/Simple-Made-Easy * Exploring four Datomic superpowers - http://www.slideshare.net/lucascavalcantisantos/exploring-four-datomic-superpowers * Learn Datalog Today - http://www.learndatalogtoday.org/ * Datomic Training Material - http://www.datomic.com/training.html * Clojure Cookbook - https://github.com/clojure-cookbook/clojure-cookbook * The Joy of Clojure, Second Edition - https://www.manning.com/books/the-joy-of-clojure-second-edition * Clojure Remote Keynote: Designing with Data - https://www.youtube.com/watch?v=kP8wImz-x4w Also listen to https://zadevchat.io/27/ for our previous discussion with Robert on Clojure. And finally our picks Robert: * "Learning Mindset" (Mindset by Carol Dweck) - http://mindsetonline.com/ * Lego - http://www.lego.com/ Thanks for listening! Stay in touch: * Homepage - https://zadevchat.io/ * Socialize - https://twitter.com/zadevchat & http://facebook.com/ZADevChat/ * Suggestions and feedback - https://github.com/zadevchat/ping * Subscribe and rate in iTunes - http://bit.ly/zadevchat-itunes

02:14 - Ben Nadel Introduction Twitter GitHub Blog Adventures in Angular Episode #029:  Angular At Work with Ben Nadel InVision @InVisionApp 02:56 - Looking at Angular 2 04:01 - Dialect and Mechanics 13:17 - Angular 2: Likes and Dislikes The Angular Learning Curve Graph 28:02 - Promises and Observables 32:11 - Change Detection ngModel 39:13 - The Mental Model 47:12 - redux Picks Ex-Con #2 (Joe) Ben's Blog (Ward) Ben Lesh: Learning Observable By Building Observable (Lukas) The Lulu (Lukas) Dropbox (Chuck) The Best Podcast Rap Video (Chuck) Tef: Write code that is easy to delete, not easy to extend. (Ben) Sandi Metz: The Wrong Abstraction (Ben) Kyle Simpson: The Economy of Keystrokes @ Thunder Plains 2015 (Ben) Rich Hickey: Simple Made Easy (Ben)

02:14 - Ben Nadel Introduction Twitter GitHub Blog Adventures in Angular Episode #029:  Angular At Work with Ben Nadel InVision @InVisionApp 02:56 - Looking at Angular 2 04:01 - Dialect and Mechanics 13:17 - Angular 2: Likes and Dislikes The Angular Learning Curve Graph 28:02 - Promises and Observables 32:11 - Change Detection ngModel 39:13 - The Mental Model 47:12 - redux Picks Ex-Con #2 (Joe) Ben's Blog (Ward) Ben Lesh: Learning Observable By Building Observable (Lukas) The Lulu (Lukas) Dropbox (Chuck) The Best Podcast Rap Video (Chuck) Tef: Write code that is easy to delete, not easy to extend. (Ben) Sandi Metz: The Wrong Abstraction (Ben) Kyle Simpson: The Economy of Keystrokes @ Thunder Plains 2015 (Ben) Rich Hickey: Simple Made Easy (Ben)

02:14 - Ben Nadel Introduction Twitter GitHub Blog Adventures in Angular Episode #029:  Angular At Work with Ben Nadel InVision @InVisionApp 02:56 - Looking at Angular 2 04:01 - Dialect and Mechanics 13:17 - Angular 2: Likes and Dislikes The Angular Learning Curve Graph 28:02 - Promises and Observables 32:11 - Change Detection ngModel 39:13 - The Mental Model 47:12 - redux Picks Ex-Con #2 (Joe) Ben's Blog (Ward) Ben Lesh: Learning Observable By Building Observable (Lukas) The Lulu (Lukas) Dropbox (Chuck) The Best Podcast Rap Video (Chuck) Tef: Write code that is easy to delete, not easy to extend. (Ben) Sandi Metz: The Wrong Abstraction (Ben) Kyle Simpson: The Economy of Keystrokes @ Thunder Plains 2015 (Ben) Rich Hickey: Simple Made Easy (Ben)

Kahlil and Henning are back from TopConf in Austria and brought some Linzer torte. Raquel reviews "2015 in review" by Sebastian McKenzie's, creator of Babel.js. A summary of "Simple Made Easy" and grand plans for the Reactive Germany tour.

Join us as we explore Clojure, the robust, practical and fast programming language. Kenneth, Kevin & Len talk to Robert Stuttaford (@RobStuttaford), co-founder and CTO of Cognician, about the Clojure programming language and his experience using it for the last few years. We discuss the language itself as well as some tools. We sing the praises of Rich Hickey, even if it just for his great talks, and stroll around the ecosystem including the obligatory stop at Datomic. Robert really did a great job of guiding us through the landscape and we're very excited about Clojure after this call. We'll definitely have Robert back in the future to cover Datomic and other parts of Clojure we didn't cover. Quick aside, the conversation was very organic and we skipped the formal introductions, and we had a few small technical snags with the recording, but the content is still great and we hope you enjoy listening as much as we did recording. Follow Robert and Cognician on the web: - https://twitter.com/RobStuttaford - http://www.stuttaford.me - http://www.cognician.com Here are some resources mentioned in the show: * emacs - https://www.gnu.org/software/emacs/ * Spacemacs - https://github.com/syl20bnr/spacemacs * Clojure Programming (O'Reilly) - http://www.clojurebook.com * Robert's emacs.d - https://github.com/robert-stuttaford/.emacs.d * Simple Made Easy by Rich Hickey - http://www.infoq.com/presentations/Simple-Made-Easy * Rich Hickey's Greatest Hits - https://changelog.com/rich-hickeys-greatest-hits/ * Lisp - https://en.wikipedia.org/wiki/Lisp_(programming_language) * DotLisp - http://dotlisp.sourceforge.net/dotlisp.htm * Clojurescript - https://github.com/clojure/clojurescript * edn (extensible data notation) - https://github.com/edn-format/edn * schema - https://github.com/plumatic/schema * Isomorphic JavaScript - http://isomorphic.net * Homoiconicity - https://en.wikipedia.org/wiki/Homoiconicity * algo.monads - https://github.com/clojure/algo.monads * Logic programming with core.logic - https://github.com/clojure/core.logic * Excel-REPL - https://github.com/whamtet/Excel-REPL * Arcadia, Clojure integration with Unity 3D - https://github.com/arcadia-unity/Arcadia * ClojureScript + React Native - http://cljsrn.org * Planck ClojureScript REPL - http://planck-repl.org * Clojure for the Brave and True - http://www.braveclojure.com * clojurians on Slack - http://clojurians.net * #clojure on Freenode * Clojure Google Group - http://groups.google.com/group/clojure * ClojureBridge - http://www.clojurebridge.org * Clojure Cup - http://www.clojurecup.com * Nikita Prokopov - https://github.com/tonsky * Datomic - http://www.datomic.com And finally our picks: Kenneth: * Simple Made Easy by Rich Hickey - http://www.infoq.com/presentations/Simple-Made-Easy Len: * Structure and Interpretation of Computer Programs - http://www.sicpdistilled.com/ * SICP Lecture Videos - http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/ Robert: * emacs - https://www.gnu.org/software/emacs/ * Mindfulness meditation - https://en.wikipedia.org/wiki/Mindfulness * Tim Ewald - Clojure: Programming with Hand Tools - https://www.youtube.com/watch?v=ShEez0JkOFw Kevin: * Spacemacs - https://github.com/syl20bnr/spacemacs * Coggle - https://coggle.it Stay in touch: * Socialize - https://twitter.com/zadevchat & http://facebook.com/ZADevChat/ * Suggestions and feedback - https://github.com/zadevchat/ping * Subscribe and rate in iTunes - https://itunes.apple.com/za/podcast/zadevchat-podcast/id1057372777 PS: We'll be at RubyFuza in Cape Town on Feb 4th & 5th, and at Devconf in Fourways on March 8th. Please come say hi!

本期节目由 思客教学 赞助，思客教学 “专注 IT 领域远程学徒式” 教育。 本期由 Terry 主持, 采访到了过纯中, 和他聊聊他与微软的爱恨情仇，说说他如何用 Windows 作为桌面来进行“开源软件”开发的。 Visual Basic Silverlight WPF RIA Jon on Software EJB J2EE Development without EJB ADO.NET Ubuntu Django ASP.NET MVC UNIX is very simple, it just needs a genius to understand its simplicity. Rich Hickey Simplicity Matters Simple Made Easy Agile Web Development With Rails Sublime Mosh Quora Ruby社区应该去Rails化了 Cuba Express Aaron Patterson Journey active_model_serializers windows PR AppVeyor Lotus Trailblazer Rails Engine Concern SPA react-rails ECMAScript 6 Ember React Angular Vue Yehuda Bower webpack React Hot Loader Flux redux alt TypeScript Anders Hejlsberg CoffeeScript Haml Slim Been Hero EventMachine Basecamp 3 wechat gem state_machine state_machines-graphviz aasm Edsger React Native 轮子哥 Special Guest: 过纯中.

02:27 - Evan Czaplicki Introduction Twitter GitHub Prezi 02:32 - Richard Feldman Introduction Twitter GitHub NoRedInk 02:38 - Elm @elmlang 04:06 - Academic Ideas 05:10 - Functional Programming, Functional Reactive Programming & Immutability 16:11 - Constraints Faruk Ateş Modernizr The Beauty of Constraints Types / Typescript 24:24 - Compilation 27:05 - Signals start-app 36:34 - Shared Concepts & Guarantees at the Language Level 43:00 - Elm vs React 47:24 - Integration Ports lunr.js 52:23 - Upcoming Features 54:15 - Testing Elm-Test elm-check 56:38 - Websites/Apps Build in Elm CircuitHub 58:37 - Getting Started with Elm The Elm Architecture Tutorial Elm Examples 59:41 - Canonical Uses? 01:01:26 - The Elm Community & Contributions The Elm Discuss Mailing List Elm user group SF Stack Overflow ? The Sublime Text Plugin WebStorm Support for Elm? Coda grunt-elm gulp-elm Extras & Resources Evan Czaplicki: Let's be mainstream! User focused design in Elm @ Curry On 2015 Evan Czaplicki: Blazing Fast HTML: Virtual DOM in Elm Picks The Pragmatic Studio: What is Elm? Q&A (Aimee) Elm (Joe) Student Bodies (Joe) Mike Clark: Getting Started With Elm (Joe) Angular Remote Conf (Chuck) Stripe (Chuck) Alcatraz versus the Evil Librarians (Alcatraz, No. 1) by Brandon Sanderson (Chuck) Understanding Comics: The Invisible Art by Scott McCloud (Evan) The Glass Bead Game: (Magister Ludi) A Novel by Hermann Hesse (Evan) The Design of Everyday Things: Revised and Expanded Edition by Don Norman (Richard) Rich Hickey: Simple Made Easy (Richard) NoRedInk Tech Blog (Richard)

02:27 - Evan Czaplicki Introduction Twitter GitHub Prezi 02:32 - Richard Feldman Introduction Twitter GitHub NoRedInk 02:38 - Elm @elmlang 04:06 - Academic Ideas 05:10 - Functional Programming, Functional Reactive Programming & Immutability 16:11 - Constraints Faruk Ateş Modernizr The Beauty of Constraints Types / Typescript 24:24 - Compilation 27:05 - Signals start-app 36:34 - Shared Concepts & Guarantees at the Language Level 43:00 - Elm vs React 47:24 - Integration Ports lunr.js 52:23 - Upcoming Features 54:15 - Testing Elm-Test elm-check 56:38 - Websites/Apps Build in Elm CircuitHub 58:37 - Getting Started with Elm The Elm Architecture Tutorial Elm Examples 59:41 - Canonical Uses? 01:01:26 - The Elm Community & Contributions The Elm Discuss Mailing List Elm user group SF Stack Overflow ? The Sublime Text Plugin WebStorm Support for Elm? Coda grunt-elm gulp-elm Extras & Resources Evan Czaplicki: Let's be mainstream! User focused design in Elm @ Curry On 2015 Evan Czaplicki: Blazing Fast HTML: Virtual DOM in Elm Picks The Pragmatic Studio: What is Elm? Q&A (Aimee) Elm (Joe) Student Bodies (Joe) Mike Clark: Getting Started With Elm (Joe) Angular Remote Conf (Chuck) Stripe (Chuck) Alcatraz versus the Evil Librarians (Alcatraz, No. 1) by Brandon Sanderson (Chuck) Understanding Comics: The Invisible Art by Scott McCloud (Evan) The Glass Bead Game: (Magister Ludi) A Novel by Hermann Hesse (Evan) The Design of Everyday Things: Revised and Expanded Edition by Don Norman (Richard) Rich Hickey: Simple Made Easy (Richard) NoRedInk Tech Blog (Richard)

02:27 - Evan Czaplicki Introduction Twitter GitHub Prezi 02:32 - Richard Feldman Introduction Twitter GitHub NoRedInk 02:38 - Elm @elmlang 04:06 - Academic Ideas 05:10 - Functional Programming, Functional Reactive Programming & Immutability 16:11 - Constraints Faruk Ateş Modernizr The Beauty of Constraints Types / Typescript 24:24 - Compilation 27:05 - Signals start-app 36:34 - Shared Concepts & Guarantees at the Language Level 43:00 - Elm vs React 47:24 - Integration Ports lunr.js 52:23 - Upcoming Features 54:15 - Testing Elm-Test elm-check 56:38 - Websites/Apps Build in Elm CircuitHub 58:37 - Getting Started with Elm The Elm Architecture Tutorial Elm Examples 59:41 - Canonical Uses? 01:01:26 - The Elm Community & Contributions The Elm Discuss Mailing List Elm user group SF Stack Overflow ? The Sublime Text Plugin WebStorm Support for Elm? Coda grunt-elm gulp-elm Extras & Resources Evan Czaplicki: Let's be mainstream! User focused design in Elm @ Curry On 2015 Evan Czaplicki: Blazing Fast HTML: Virtual DOM in Elm Picks The Pragmatic Studio: What is Elm? Q&A (Aimee) Elm (Joe) Student Bodies (Joe) Mike Clark: Getting Started With Elm (Joe) Angular Remote Conf (Chuck) Stripe (Chuck) Alcatraz versus the Evil Librarians (Alcatraz, No. 1) by Brandon Sanderson (Chuck) Understanding Comics: The Invisible Art by Scott McCloud (Evan) The Glass Bead Game: (Magister Ludi) A Novel by Hermann Hesse (Evan) The Design of Everyday Things: Revised and Expanded Edition by Don Norman (Richard) Rich Hickey: Simple Made Easy (Richard) NoRedInk Tech Blog (Richard)

Ben talks with Pete Hunt, formerly of Facebook & Instagram, on React and what makes this unique JavaScript library tick, as well as shifting from a technical to a business focused mindset. React Fielding Dissertation Simple Made Easy- Rich Hickey Pete on Twitter