Playerself

playerself

I wish I could title this post “How Pacifism Wins at life” since it’d immediately make everything much easier (especially writing this post), but as most well-meaning kids swiftly learn on the playground - the world is not gentle. It’s always bothered me how impossible it is to negate the need for strength in life (whether physical, emotional, individual, or collective), especially considering how unevenly and unfairly that stat is usually distributed. What bothers me even more, however, is how many people I’ve seen gleefully misapply and overfit this fact, falsely concluding that since one cannot survive without strength, it is the only meaningful form of power in the world. I’m sure you’ve seen these people too. There is another side to this coin, however. One that I care deeply about, and that carries just as much weight and impact as anything mentioned above: if you ever want to get anywhere as a person, society, or species, either. you can’t afford to negate gentleness We’re gonna dive into game theory here, so if you’re new to/rusty on the terminology, the single best thing you can do is click for a brilliant interactive crash course on all the meaningful bits. If you’re short on time you’re better off prioritizing this click rather than reading the rest of this post (Nicky Case is amazing)! Quick note: here Many smartass variations of have been cooked up over the years, with each change in the parameters of the game bringing along with it a new balance of incentives, and different winning strategies accordingly. the prisoner’s dilemma Should you make like and always turn the other cheek, or should you play like Lucifer himself and ruthlessly exploit everyone you meet? Maybe you need a complex web of conditions defining how you act towards others based on your relationship so far, or maybe you can just do unto others as they do unto you. Jesus Every variation teaches us something new about the dynamics of selfishness and selflessness, trust and defection, all while generating a rich abundance of smug nerds to debate which ones apply best to which real-life situation. Debate is cool and all, but what I don’t understand is why all said nerds don’t just stop and yell out in unison: WE’VE ACTUALLY KINDA SOLVED IT! Because we actually kinda already have, and the result is beautiful. Let’s start with an overview of the most impactful conditions of any prisoner’s dilemma, and select the ones that reflect the environment of the real world best. We’re doing this to establish that whatever we end up discovering later on which can demonstrably, empirically, and objectively thrive under these conditions - must be the brilliant strategy best applied to the majority of real-life situations. mysterious strategy Let’s get to it: Most real-life situations (whether between people or nations) are not one-time events, but rather involve repeated interactions over time. With the exception of aggressive drunks outside pubs, we usually develop a long-term repertoire of past actions with one another. To clarify, even a single conversation can technically be defined as a “repeated interaction” (so long as each side gets more than 1 line of dialogue each)! Repeated/ - One-off Rounds We have imperfect information about each other's intentions, payoffs, and the consequences of our actions. Plenty of room for error. Imperfect/ - Perfect Information We can certainly communicate with one another, whether explicitly or implicitly. Misunderstandings, bluffs and lies are completely possible, but are forms of communication nonetheless. Communication: On/ - Off The cost/reward for defection/co-operation vary greatly between contexts. This is likely the highest variance condition here. Asymmetric/ - Symmetric Payoffs Groups can grow, shrink, merge and split depending on the actions of their members. Furthermore, interactions can be between, and affect, multiple participants at once. Variable/ - Constant Group Size Anger, fear, empathy, can all affect decision making. That’s not even mentioning cognitive biases (#UncleKahneman). Emotionality: On/ - Off Nobody knows anything about anything or anyone for sure and we’re all terrified mortal coils. The technical term for this is and . Uncertainty: So On It Hurts/ - Off Environmental Uncertainty Social Uncertainty Right! This should be a sturdy enough foundation (let me know if I’ve missed anything important in the comments). The stage is set, and you’re now ready to hear about one of the most illuminating experiments done in the field of game theory, but in a shortened tl;dr manner. This is mainly because I suspect a significant portion of you have already heard some version of this before, and that the other, equally significant portion of you that hasn’t, would enjoy it being covered while favouring promptness. To the remaining, probably much tinier portion of you (yet still equally significant!) that would actually love to read a full breakdown - I can only humbly ask for your forgiveness and direct you . Quick note: here The gist is this: in the 60s, a super influential game theory researcher (named Axelrod) invites other super influential game theory researchers from around the world to devise their ultimate prisoner’s dilemma strategy, code it, and then let the resulting programs fight each other to the death in a grand digital petri dish. The tournament is kinda like a turn-based RPG (with depleting hit points and everything), except that at the end of each fight, whichever program wins gets to survive and reproduce (just like in biology)! Whoever spawns enough offspring to eventually take over the board is the winning strategy. Thousands of lines of code riddled with complexity were submitted, ranging from the most ruthless of programs to the kindest. They were then all promptly fired up and sicced at each other for 200 rounds. Soon enough one winner stood supreme, and it was poetically too good to be true too, since it was only two humble lines of code: Rule 1 - Be nice (technically meaning always co-operate on the first round).

Rule 2 - From then on just copy what the other player did in the previous round (meaning an eye for an eye and a hug for a hug). What a tear-jerking win for ancient wisdom! Literally, every major religion has described its own variation of a “do unto others as they do unto you” principle at some point or another, crystallizing a timeless insight out of pure intuition and an astute observation of life’s dynamics. In this case, the strategy was simply called Tit for Tat. It’s a wise strategy, and fully compatible with life’s continuous demand for strength as a deterrent, plus it also manages to incorporate an impressive dose of goodwill. The conclusion is super simple too: you should always attempt to come in peace, bravely placing your trust in others at risk of getting hurt. However, should they try to harm you, don’t hesitate to retaliate back and teach them a lesson. Sounds good, but NOT GOOD ENOUGH!!! As I’m sure you’ve noticed, the conditions of the experiment above don’t quite satisfy the requirements we initially established as necessary to make its conclusion fully applicable to real life (and besides, I still owe you an Adjective). Let’s quickly review the criteria one by one and see where we stand: : - There were 200 of them! Repeated Rounds TRUE : - Programs didn’t know the strategy of their opponents ahead of time. Imperfect Information TRUE : - The programs couldn’t chit-chat or gossip. Communication On FALSE - The cost/reward matrix for co-operate/defect was symmetrical and constant. Asymmetric Payoffs: FALSE - While programs technically fought 1v1, the outcome of each fight affected the overall group representation of each program on the board. Each win increased the probability that a program will meet a like-minded partner and directly influenced the viability of its strategy. Variable Group Size: TRUE - The programs never got to learn about love. Emotionality On: FALSE While the programs certainly suffered from , not knowing how their adversary would react, they did enjoy the very important luxury of , with perfect reliability for inputs and outputs, and no risk of earthquakes. Uncertainty On: HALF TRUE - Social Uncertainty Environmental Certainty It seems we're missing , , and . Close but no cigar. Communication Emotionality Environmental Uncertainty, Asymmetric Payoffs Briefly setting aside Asymmetric Payoffs (don’t worry, they’ll come back soon), what I’m hoping you’ll notice is that the remaining three conditions are all different manifestations of the same messy, real-world principle: sometimes, things can go horribly wrong by complete accident. More specifically, there’s always the potential for Miscommunication, Miscalculation, Mistake, and Mishap. In a world full of Tit for Tats, any of these can lead to a catastrophic cycle. Ominous Ms Say two Tit for Tats run into each other in real life. Both are immediately nice to one another and begin to reciprocate said niceness ad infinum. is within reach. However, throughout the entirety of their relationship, all it would take is one tiny error, one tragic misplaced M by either one, to immediately initiate an ever-escalating cycle of mutual retaliation until one or both drop dead. Utopia In practice, Tit for Tat can actually be a pretty disastrous strategy, since it can easily get you deadlocked in a costly conflict. Whether its a war that’s fought until there’s no one left to fight, two political rivals forced to dedicate an ever-increasing segment of their campaign budget to disparaging one another’s public image, or simply a battle of pettiness between middle management and employees - in the real world, you can’t ignore the need for some form of de-escalation mechanism. Even if it’s costly, you find a way to cut terrible feedback loops. You need one additional power: Get a load of this: must GENTLENESS! So long as you possess the strength to defend yourself, you can always make the choice to generously give someone the benefit of the doubt, relinquish a justified retaliatory response, or most gently of all, simply decide to forgive. Why? All for the sake of valiantly fighting to keep the option for peace and collaboration open at all times, lest it get closed off forever to everyone’s mutual detriment. I can’t think of a more heroic struggle. Being generously gentle means you’re prepared to get hurt in the name of peace, and it’s an incredibly brave and risky thing to do. How risky? Asymmetrically so! (I told you they’d be back) are all around us, since in real life no two players ever engage on equal footing. Each player has a different ratio between how much they want something, what it’d cost them to get it, and what capabilities are at their disposal. The risk/reward matrix is always dynamic and far from symmetric between players. Asymmetric Payoffs The defining variable here, unfortunately, is strength (we knew it was inescapable from the get-go). This certainly complicates the decision-making calculus, but it certainly doesn’t negate the role of gentleness! Luckily, in real life, the asymmetry goes both ways: Even when facing a “stronger” player, who says you have to engage with asymmetric strength symmetrically? There are many kinds of rewards, and one form of strength can be completely negated by another (think of the difference between Tank vs Tank and Tank vs RPG). Furthermore, since : , outcomes are always unpredictable for sides - each one could potentially outmaneuver, attrition, shift vectors, or just plain luck out vs the other, regardless of the perceived reward matrix. Uncertainty On both Asymmetric Payoffs are merely a complicating factor, but the key principle still stands: In the long run, the cost incurred each time you attempt to cooperate and get exploited usually pales in comparison of the cost of never trying at all. With our newly acquired wisdom, let’s return to the original Tit for Tat strategy, and custom fit it with a mechanism for self-correction. We just need to add one rule: Rule 1 - Be nice (technically meaning always co-operate on the first round).

Rule 2 - From then on just copy what the other player did in the previous round (meaning an eye for an eye and a hug for a hug).

Rule 3 - After you retaliate, always try to co-operate again in the next round. Congratulations! (coined by Axelrod himself)! It maintains the key benefits of regular Tit for Tat, while possessing the ability to break out of cycles should they arise. We’ve also finally come full circle to the title of this post! It’s been emotional. We’ve just created “Generous Tit for Tat” Ominous M This strategy can be dangerous, counter-intuitive, and painful, that’s why it requires such a unique kind of boldness - but the fact of the matter is, it’s one of the strongest strategies for winning at life in the long term. Whether between individuals/communities/corporations/nations. It’s gonna be tough, but never forget: if you don’t go around actively trying to exploit others, are strong enough to protect yourself when others do, and have the discipline within you to remain gentle and forgiving despite it all - you’ve already done humanity an incredible service by just you being you. Wear whatever scars you collect on your journey with pride! The End! If you enjoyed our little adventure, you’re super invited to join the next one! Also published here.

Game Theory’s Ultimate Answer to Real World Dilemmas: “Generous Tit for Tat”

No one could have planned this, but time-loops and roguelikes became an important source of therapy for many of us in a post-pandemic world. Ironically enough, 2020-2021 has seen more games centered around repetition than ever before. The increasingly popular genre of Roguelike games have permeated the gaming market while other titles have been exploring the narrative premise of time loops. Why so many? Why now? I think there are functional reasons for this genre becoming the Zeitgeist of the gaming industry, such as adapting to increasing development costs. However, the coincidence of a worldwide pandemic that forced many to stay home and live increasingly repetitive lives has created some unintended draw to these games that suddenly became much more relevant. Time-loops vs. Roguelikes: What’s the Difference? Time-loops and Roguelikes share many similarities and are often confused with one another. While both revolve around repetition, there are important distinctions to point out: A genre of video game in which the player must return to the beginning of the game upon every death. Roguelikes: Gameplay can either be fixed (meaning the game has the same map, challenges and enemies) or randomly generated (the game changes every playthrough). The goal is often to complete the entire game without dying, emphasizing the skill of a player in a high-stakes environment. Some games in the genre allow for players to gain weapons, skills and upgrades that can be used even after the player dies, making progression easier. Some require players to start every game from scratch. Roguelikes typically boast punishing difficulty and high replayability in order to master. (Examples: Rogue Legacy, Spelunky, Hades, Dead Cells) Games that focus narratively on a story in which time repeats itself. Typically, a character is reliving the same day or time period over and over. Time-loops: Players progress through a story that has some sort of time or space limitation, and must accomplish a goal for the character. Time-loop video games have less strict gameplay functions than Roguelikes. Narratives dictate gameplay that can be fixed or randomly generated. Some will use a repetitive environment with repeat characters, but make playthroughs feel significantly different based on the story's progression. (Examples: Returnal, Deathloop, 12 Minutes) While these two genres may intersect, they are not mutually exclusive. Deathloop for example, has some elements of a Roguelike: you start the same day over on a beach and lose any weapons or abilities that you didn’t use the in-game currency (Residium) to ‘save’. However, Deathloop is not a Roguelike because every playthrough is different and progression is through the narrative not gameplay. Every time Colt restarts his day, you have new information and goals, so you are rarely replaying the same section or attempting the same challenge. Returnal on the other hand, checks boxes for both time-loops and roguelikes. The game follows an astronaut who is stuck on a hostile planet. Every time she dies, which is often, she finds herself back at her crash site. This game is also a roguelike in that in order to progress through the game, players must progress through the same randomly generated regions of this planet in order. Why Time-loops and Roguelikes Make Sense for Game Development Despite seeming overly repetitive, we see that there are plenty of unique ways developers can put a twist on these two genres to get very different feeling games--like Returnal and Deathloop this year for example. There are plenty of gameplay and narrative threads to use and make these games feel fresh. It makes sense for publishers to push their creativity in this way-- it can potentially save them money. Developing video games is getting more expensive than ever, and adaptation is necessary. Games that feature repetition can be a great way to cut costs. Time-loops and roguelikes often only need one small environment to make a full game. Compared to something expansive like Red Dead Redemption 2 or Skyrim, that is a substantial amount of time and money saved on asset creation. You don’t need to make as many models or environments. Instead, you can focus on gameplay and story. In theory, you can create a game in less time and with a smaller team. However, the challenge then becomes finding a creative way to build an addictive gameplay loop that makes the repetition worth coming back to again and again. The Irony of Catharsis: Feeling Stuck It’s fair to say that a lot of us feel stuck nowadays. As social-distancing, shelter-in-place and work-from-home has become normal rhetoric around the world, there seems to be less opportunity for self-betterment and progression. It’s coincidental that Time-Loops and Roguelikes, both genres of games that resist a player's self-betterment and progression, are so popular. The reason for this could be their cathartic value. When we face our fears and anxieties through others, it often helps us better deal with the negative emotions associated with them. The effect is similar to watching horror movies. When we watch a horror movie, we are often witnessing our deepest fears realized in a fictional character. However, as an omniscient viewer to the horrors of the film's victims, we remain unscathed and can feel the delight of seeing the figurative light of day on the other side of the film. Seeing the end of fictional fear helps us better see our own emotions as temporary, and that there is a sunnier side to our anxieties. With time-loops and roguelikes, we are faced with the feelings of being stuck in a fictional environment. By facing these feelings and very real frustrations playing a difficult game, it can help us deal with similar anxieties associated with a post-pandemic world. The feeling of being sent back to the lowest level of Hades for example, can feel oddly similar to waking up to face another mundane day. But, like in Hades, the key to progress is to simply keep moving. Powering Through: Time-Loops and Roguelikes Game Strategies I turned to Hades early on in the pandemic. I was classified as an essential worker, so my everyday routine was both highly stressful and highly repetitive and incredibly boring. Hades felt conspicuously similar to my new COVID-19 lifestyle. In trying to help Zagreus get through the stressful levels of Hell I would constantly find myself hitting a wall, feeling like any further progress was futile. And yet, I just kept playing. After a few tries, I would always get a little bit farther. This is where the real magic lies in Time-Loop and Roguelike game strategy--you must keep trying. Few people become skilled at these games quickly. It takes a lot of repetition, and often a lot of dying, to improve and progress. That’s why in many of these games, a player death count is readily displayed like a badge of honor. (“only” took me 50 tries to escape Hell in Hades!). Because you, the player, are gaining skill through practice and through small upgrades gained throughout the game, a game like Hades turns a player into a master. Those early sections and bosses that are so intimidating at first, become a breeze. That feeling of accomplishment and release of the stress involved from overcoming those “impossible” challenges are the cathartic moments I needed to help feel more hopeful about the real world. With how popular games like Hades, Deathloop, Returnal and 12 Minutes have become, I don’t think I am alone. Healing and Growing Through Game Narratives Even more than the gameplay loop, many of the narratives in these games reinforce positive messages regarding anxiety. Without getting into spoilers, the top time-loop and roguelike video games to come out in the last few years have endings that across the board emphasize themes like: Reconnecting with family Accepting yourself Embracing your present situation despite the hardships Honesty and openness These are many coping mechanisms for anxiety that are . recommended by health professionals These games also give you the player and the characters plenty of good reasons to return to their initial cause of suffering. After escaping Hell as Zagreus, and breaking the time loop as Colt in Deathloop, I immediately found myself jumping back in for more. Because, many of these games do an excellent job at empowering players who stick around for the long haul. Because most of these modern time-loop and roguelikes are heavily focused on story, the motivation in your own journey through these difficult games accentuates the character you empathize with. This makes the euphoric release from being able to tear apart the world that beat you down for hours upon hours twice as sweet. Final Thoughts Compared to other art forms, video games are very much still finding their stride. Developers are discovering new ways to create and tell stories with the unique features available to them. And, they are learning to adapt to the challenges like labor cost and development time. These intricacies sometimes lead to trends, like we see with so many Time-loop and Roguelike games in 2021. Almost as an act of fate, this zeitgeist in gaming happened to show how useful video games can be during a world-changing pandemic. The better we understand how games are evolving and how we relate to them emotionally, the more effective they will be in helping us face the constantly shifting world around us.

Time-Loops and Roguelikes: Unlikely Teachers in a Post-Pandemic World

Playing Checkers With Genetic Algorithms: Evolutionary Learning in Traditional Games

জেনেটিক অ্যালগরিদম দিয়ে চেকার খেলা: ঐতিহ্যগত গেমে বিবর্তনীয় শিক্ষা

Dame spielen mit genetischen Algorithmen: Evolutionäres Lernen in traditionellen Spielen

Jugar a las damas con algoritmos genéticos: aprendizaje evolutivo en juegos tradicionales

Jouer aux dames avec des algorithmes génétiques : apprentissage évolutif dans les jeux traditionnels

जेनेटिक एल्गोरिदम के साथ चेकर्स खेलना: पारंपरिक खेलों में विकासवादी शिक्षा

遺伝的アルゴリズムを使用したチェッカーのプレイ: 従来のゲームにおける進化的学習

유전 알고리즘으로 체커 게임하기: 전통 게임의 진화 학습

Jogando Damas com Algoritmos Genéticos: Aprendizagem Evolutiva em Jogos Tradicionais

Игра в шашки с использованием генетических алгоритмов: эволюционное обучение в традиционных играх

Genetik Algoritmalarla Dama Oynamak: Geleneksel Oyunlarda Evrimsel Öğrenme

Chơi cờ đam bằng thuật toán di truyền: Học tập tiến hóa trong các trò chơi truyền thống

用遗传算法玩西洋跳棋：传统游戏中的进化学习

Creating Your Own 3D Shooter Using the React and Three.js Stack — Part 1

প্রতিক্রিয়া এবং Three.js স্ট্যাক ব্যবহার করে আপনার নিজস্ব 3D শ্যুটার তৈরি করা — পার্ট 1

Erstellen Sie Ihren eigenen 3D-Shooter mit dem React- und Three.js-Stack – Teil 1

Creando tu propio shooter 3D usando React y Three.js Stack - Parte 1

Créer votre propre jeu de tir 3D à l'aide de la pile React et Three.js - Partie 1

रिएक्ट और थ्री.जेएस स्टैक का उपयोग करके अपना खुद का 3डी शूटर बनाना - भाग 1

React と Three.js スタックを使用して独自の 3D シューターを作成する — パート 1

React와 Three.js 스택을 사용하여 나만의 3D 슈터 만들기 - 1부

Criando seu próprio jogo de tiro 3D usando React e Three.js Stack - Parte 1

Создание собственного 3D-шутера с использованием стека React и Three.js — Часть 1

React ve Three.js Stack'ı Kullanarak Kendi 3D Shooter'ınızı Oluşturma - Bölüm 1

Tạo game bắn súng 3D của riêng bạn bằng cách sử dụng ngăn xếp React và Three.js - Phần 1

使用 React 和 Three.js 堆栈创建您自己的 3D 射击游戏 — 第 1 部分

Earlier this year, I created a really fun project that I called "Brain to the Cloud" where I saved my brain data to the cloud while playing Call of Duty so that I could analyze the relationship between my cognitive function and video game performance. I wrote up a three-part blog post series and created some fun videos to summarize my findings on that project. If you'd like to check those out, you can refer to the links at the bottom of this post. A few months after I published that project, I started working at Twitch as the lead Developer Advocate for Amazon Interactive Video Service (Amazon IVS) - a fully managed solution for creating live, interactive video streaming solutions (check out to learn more). The next step of my "Brain to the Cloud" project was obvious - I needed to my brain. this series live stream Broadcasting My Brain Before we look at the code, let's see the final product. There are 2 views for the application: a broadcasting view, and a playback view. In the broadcasting view, we can preview the live video, start the broadcast, and connect the Muse headband to stream the brain data obtained from the headband. In the playback view, we display the live stream with a element, and chart the brain data in real-time <video> Project Overview There are 5 steps to this project: Broadcast live stream Capture brain data Publish brain data as timed metadata within the live stream Playback live stream Listen for timed metadata and render brain data in a chart in real-time If you prefer graphical depictions of such things, here's how this looks: Building the Project I used React for this project. Why? Well, I've got plenty of experience with Vue and Angular, but I'm probably one of the last developers on earth to try React. I figured it was about time to figure out what all the hype was about, and I knew that this would not be a difficult project to build with it. Due to my lack of prior experience, I'm not what you'd call an "advanced" user of the framework, but I have to say that I'm pretty happy with what I see so far. I found the process enjoyable and did not find myself "fighting" with the framework. But this blog post isn't about my opinion on JavaScript frameworks, so I'll save that for a future post. Instead, let's talk about how I broadcast my brain! The Hardware In my original "Brain to the Cloud" project, I used a "vintage" EEG headset called a MindFlex to capture my brain readings. It worked fairly well but required me to "hack" the device by adding an ESP-12 microcontroller in order to pull the readings off of the device and send them to the cloud. This time I reached for something slightly newer - and something that I could use with no modifications. After a bit of research, I settled on the . Thankfully, there is a really awesome open-source library called which lets me access the brain readings directly in a web browser with Web Bluetooth (in supported browsers, of course). Muse S Headband muse-js The Live Stream Broadcast Until recently, live streaming with IVS required us to use a third-party client to broadcast our streams as RTMPS. But we recently launched a game-changer: the . As the name implies, this SDK gives us the ability to broadcast our live stream via WebRTC directly from a web browser. Clearly, this was a perfect fit for live streaming my brain since it means that I can create an "all-in-one" solution for broadcasting my brain data along with my live stream without relying on third-party software or external scripts. Amazon Amazon IVS Web Broadcast SDK Adding Web Broadcast to the React App We're not going to look at every single step required to utilize the Web Broadcast SDK in this post. Instead, we'll look at the highlights to get a general idea of how it works. Don't worry - I've got another post coming soon where we'll dig into the "step-by-step" process for using the Web Broadcast SDK, so stay tuned for that. That said, let's take a quick journey to see how I used the SDK in this project. My first step was to use a web broadcast to install the module. Using your favorite package management tool, run: amazon-ivs-web-broadcast $ npm install amazon-ivs-web-broadcast Next, we need to import it into our component. In my Broadcast.jsx component, I added: import IVSBroadcastClient, { STANDARD_LANDSCAPE } from 'amazon-ivs-web-broadcast' ; We can create an instance of the IVSBroadcastClient with the desired stream configuration and ingest the endpoint from our Amazon IVS channel and set it into our component's state. })
}); this .setState({ broadcastClient : IVSBroadcastClient.create({ streamConfig : STANDARD_LANDSCAPE, ingestEndpoint : this .state.ingestEndpoint, Now that we've got an instance of the client, we can add our camera to the client. For this we use . navigator.mediaDevices.getUserMedia() }, },
    },
}); const streamConfig = STANDARD_LANDSCAPE; const videoStream = await navigator.mediaDevices.getUserMedia({ video : { deviceId : { exact : this .state.selectedVideoDeviceId }, width : { ideal : streamConfig.maxResolution.width, max : streamConfig.maxResolution.width, height : { ideal : streamConfig.maxResolution.height, max : streamConfig.maxResolution.height, this .state.broadcastClient.addVideoInputDevice(videoStream, 'camera1' , { index : 0 }); Adding the user's microphone to the client follows a similar pattern. },
}); const audioStream = await navigator.mediaDevices.getUserMedia({ audio : { deviceId : this .state.selectedAudioDeviceId this .state.broadcastClient.addAudioInputDevice(audioStream, 'mic1' ); Because of the browser security model, we need to get permissions to access the user's camera and microphone. Refer to the for more information on this, and to see how I captured a list of devices and presented them in a dialog to allow the user to choose the broadcast device if multiple options are available. Note: project source on GitHub Now we can add a live preview to the page so that we can see what our viewers will ultimately see on the player side of things. <canvas ref={ this .previewRef} id= 'broadcast-preview' ></canvas> And attach the preview to the : broadcastClient this .state.broadcastClient.attachPreview( this .previewRef.current); To start the broadcast, add a button to the page, and in the handler for the button call on the (passing the necessary ). onClick startBroadcast() broadcastClient streamKey this .state.broadcastClient.startBroadcast( this .state.streamKey); Obtaining My Brain Data As I mentioned above, I used the library, which provides the ability to connect to the headband and pull the raw data. However, does not calculate the absolute band powers for the EEG data. For this, I needed to reach for : . muse-js muse-js another library eeg-pipes The first step is to add and import the libraries. $ npm install @neurosity/pipes $ npm install muse-js import { zipSamples, MuseClient } from 'muse-js' ; import { powerByBand, epoch, fft } from '@neurosity/pipes' ; Next, I added a button with a click handler. In the handler, I connect to the headset, start listening for data, and subscribe to the stream. zipSamples(client.eegReadings)
  .pipe( powerByBand(),
  )
  .subscribe( }
); const client = new MuseClient(); await client.connect(); await client.start(); epoch({ duration : 1024 , interval : 250 , samplingRate : 256 }), fft({ bins : 256 }), ( data ) => { const ch0 = [data.delta[ 0 ], data.theta[ 0 ], data.alpha[ 0 ], data.beta[ 0 ], data.gamma[ 0 ]]; const ch1 = [data.delta[ 1 ], data.theta[ 1 ], data.alpha[ 1 ], data.beta[ 1 ], data.gamma[ 1 ]]; const ch2 = [data.delta[ 2 ], data.theta[ 2 ], data.alpha[ 2 ], data.beta[ 2 ], data.gamma[ 2 ]]; const ch3 = [data.delta[ 3 ], data.theta[ 3 ], data.alpha[ 3 ], data.beta[ 3 ], data.gamma[ 3 ]]; const meta = [ch0, ch1, ch2, ch3]; //publish metadata Publishing my Brain Data as Timed Metadata Now that I've got a handler that collects my brain data from the Muse headband, it's time to publish that data as timed metadata in the live stream. The awesome thing about is that it is directly embedded in the video stream, and remains a permanent part of that stream. That means that it exists even in recorded versions, meaning that even in on-demand playback we can listen for and respond to the events. timed metadata The Web Broadcast SDK does not support publishing timed metadata from the client side, so we'll have to use ( ) via the . For this, I created an AWS Lambda function. putMetadata docs AWS SDK for JavaScript }); }, }; } } } } }; } response.body = err.stack; }

}; const AWS = require ( 'aws-sdk' ); const ivs = new AWS.IVS({ apiVersion : '2020-07-14' , region : 'us-east-1' exports .send = async (event, context, callback) => { // response object const response = { 'statusCode' : 200 , 'headers' : { 'Access-Control-Allow-Origin' : '*' , 'Access-Control-Allow-Methods' : 'OPTIONS,GET,PUT,POST,DELETE' , 'Content-Type' : 'application/json' 'body' : '' , 'isBase64Encoded' : false // parse payload let payload; try { payload = JSON .parse(event.body); catch (err) { response.statusCode = 500 ; response.body = JSON .stringify(err); callback( null , response); return ; // validate payload if (!payload || !payload.channelArn || !payload.metadata) { response.statusCode = 400 ; response.body = 'Must provide, channelArn and metadata' ; callback( null , response); return ; // check payload size let byteLength = Buffer.byteLength(payload.metadata, 'utf8' ); if (byteLength > 1024 ) { response.statusCode = 400 ; response.body = 'Too big. Must be less than or equal to 1K' ; callback( null , response); return ; // putmetadata input let params = { channelArn : payload.channelArn, metadata : payload.metadata try { await ivs.putMetadata(params).promise(); response.statusCode = 200 ; response.body = JSON .stringify({ 'published' : true }, '' , 2 ); callback( null , response); catch (err) { response.statusCode = 500 ; callback( null , response); return ; To publish my brain data as timed metadata, I created an Amazon API Gateway to invoke the function and modify the method above to call the AWS Lambda function. subscribe() .pipe( powerByBand(),
  )
  .subscribe( fetch(LAMBDA_URL, { }, })
        });
      }
    }
  ); zipSamples(client.eegReadings) epoch({ duration : 1024 , interval : 250 , samplingRate : 256 }), fft({ bins : 256 }), ( data ) => { const ch0 = [data.delta[ 0 ], data.theta[ 0 ], data.alpha[ 0 ], data.beta[ 0 ], data.gamma[ 0 ]]; const ch1 = [data.delta[ 1 ], data.theta[ 1 ], data.alpha[ 1 ], data.beta[ 1 ], data.gamma[ 1 ]]; const ch2 = [data.delta[ 2 ], data.theta[ 2 ], data.alpha[ 2 ], data.beta[ 2 ], data.gamma[ 2 ]]; const ch3 = [data.delta[ 3 ], data.theta[ 3 ], data.alpha[ 3 ], data.beta[ 3 ], data.gamma[ 3 ]]; const meta = [ch0, ch1, ch2, ch3]; // put metadata if broadcasting if ( this .state.isBroadcasting) { 'method' : 'POST' , 'mode' : 'no-cors' , 'headers' : { 'Content-Type' : 'application/json' , 'body' : JSON .stringify({ channelArn : this .state.channelArn, metadata : JSON .stringify(meta) Building the Live Stream Playback and Charting My Brain Data Once the live stream with brain data broadcast view was complete, it was time to create a playback experience that would display the live stream and chart the brain data in real time as it came in via timed metadata. Creating The Live Stream Player We can use the IVS Web Player SDK via NPM, but since it uses WebAssembly . To avoid that trickiness, I find it easier to use the web player via a tag and I added that to my in my React app. things can get tricky <script> index.html <script src= "https://player.live-video.net/1.12.0/amazon-ivs-player.min.js" ></script> In my component, I grab a reference to the player and some necessary elements. Playback.jsx const { IVSPlayer } = window ; const { create : createMediaPlayer, isPlayerSupported, PlayerEventType, PlayerState } = IVSPlayer; const { ENDED, PLAYING, READY, BUFFERING } = PlayerState; const { TEXT_METADATA_CUE, ERROR } = PlayerEventType; For playback, we use the native tag. <video> <video ref={ this .videoRef} controls playsInline></video> And to initialize the player and start playback: this .playerRef.current = createMediaPlayer(); this .playerRef.current.attachHTMLVideoElement( this .videoRef.current); this .playerRef.current.load(STREAM_URL); this .playerRef.current.play(); Listening and Responding to Timed Metadata Now that we're playing the live stream, we can listen for and respond to the incoming brain data. this .playerRef.current.addEventListener(TEXT_METADATA_CUE, this .onPlayerMetadata); Set the brain data into our component state: });
  });
}; onPlayerMetadata = ( e ) => { //console.log(e); const data = JSON .parse(e.text); this .setState( state => { state.ch0.datasets[ 0 ].data = data[ 0 ]; state.ch1.datasets[ 0 ].data = data[ 1 ]; state.ch2.datasets[ 0 ].data = data[ 2 ]; state.ch3.datasets[ 0 ].data = data[ 3 ]; this .chartReferenceCh0.current.data.datasets[ 0 ].data = state.ch0.datasets[ 0 ].data; this .chartReferenceCh1.current.data.datasets[ 0 ].data = state.ch1.datasets[ 0 ].data; this .chartReferenceCh2.current.data.datasets[ 0 ].data = state.ch2.datasets[ 0 ].data; this .chartReferenceCh3.current.data.datasets[ 0 ].data = state.ch3.datasets[ 0 ].data; return ({ ch0 : state.ch0, ch1 : state.ch1, ch2 : state.ch2, ch3 : state.ch3 And render it with a bar chart (with Chart.js): options={
    { }, } 
    }
  } /> <Bar data={ this .state.ch0} ref={ this .chartReferenceCh0} aspectRatio : 1 , title : { display : true , text : 'Channel: ' + channelNames[ 0 ] }, responsive : true , tooltips : { enabled : false legend : { display : false The visualization is cool, and certainly provides a fun way to see my brain data while I'm live streaming a game, but doesn't provide a ton of context. So I figured it would make sense to include some calculations to give insight into what the data actually means. For that, I found some calculations in the which included some formulas that can be used to calculate factors like relaxation (alpha divided by delta), and concentration (beta divided by theta). Another a way to derive fatigue ((theta + alpha) / beta). I wrapped these calculations up in a handy, reusable component. muse-lsl project on GitHub great blog post I found highlighted </Col> </Row> <Row className= 'mb-2' > { /* Delta: 0 Theta: 1 Alpha: 2 Beta: 3 Gamma: 4 */ } <Col xs={ 12 } xxl={ 4 } className= 'align-items-center mb-2 mb-xxl-0' > < Badge className = 'fs-6 w-100' bg = 'info' > Relaxation: < span className = 'fw-bold' > < NumberFormat value = {this.props.dataset.data[0] ? ( this.props.dataset.data [ 2 ] / this.props.dataset.data [ 0 ]) : 0 } decimalScale = {2} displayType = { ' text '} /> </ span > </ Badge > < Col xs = {12} xxl = {4} className = 'align-items-center mb-2 mb-xxl-0' > < Badge className = 'fs-6 w-100' bg = 'info' > Fatigue: < span className = 'fw-bold' > < NumberFormat value = { this.props.dataset.data [ 3 ] ? ( ( this.props.dataset.data [ 1 ] + this.props.dataset.data [ 2 ]) / this.props.dataset.data [ 3 ] ) : 0 } decimalScale = {2} displayType = { ' text '} /> </ span > </ Badge > </ Col > < Col xs = {12} xxl = {4} className = 'align-items-center mb-2 mb-xxl-0' > < Badge className = 'fs-6 w-100' bg = 'info' > Focus: < span className = 'fw-bold' > < NumberFormat value = {this.props.dataset.data[1] ? ( this.props.dataset.data [ 3 ] / this.props.dataset.data [ 1 ]) : 0 } decimalScale = {2} displayType = { ' text '} /> </ span > </ Badge > </ Col > Summary In this post, we looked at how I created a React application to live stream my brain data with Amazon IVS. If you'd like to learn more about Amazon IVS, please check out the series here on dev.to. If you're interested in trying out the application or just checking out the full source for the application, check it out on . Your comments, questions and feedback is always welcome, so leave a comment here or connect with me on Getting Started with Amazon Interactive Video Service GitHub Twitter Links Brain to the Cloud - Part I - Project Intro and Architectural Overview Brain to the Cloud - Part II - How I Uploaded My Brain to the Cloud Brain to the Cloud - Part III - Examining the Relationship Between Brain Activity and Video Game Performance Project Source Code First Published . here

How I Live Stream My Brain with Amazon IVS, a Muse Headband and React

Cómo transmito en vivo mi cerebro con Amazon IVS, una diadema Muse y React

Comment je diffuse en direct mon cerveau avec Amazon IVS, un bandeau Muse et React

मैं कैसे अपने दिमाग को Amazon IVS, एक सरस्वती हेडबैंड और रिएक्ट के साथ लाइव स्ट्रीम करता हूं

Amazon IVS、Muse ヘッドバンド、React を使用して脳をライブ ストリーミングする方法

Como eu transmito meu cérebro ao vivo com o Amazon IVS, uma bandana Muse e React

Cách tôi phát trực tiếp bộ não của mình với Amazon IVS, Muse Headband và React

我如何使用 Amazon IVS、Muse 头带和 React 直播我的大脑

In our last post, we created our first instance of the Amazon Interactive Video Service (Amazon IVS) player to playback the live stream that we previously created. Today, we'll look at the various methods and events that are available in the Amazon IVS Player that we can use to enhance the user experience when playing back a live stream. Recap Let's quickly revisit the Amazon IVS player that we created in our last post, just to give us a starting point to build on in this post. To recap, in order to playback an Amazon IVS live stream, we included the Amazon IVS player , added a element, and then used a bit of JavaScript to create the player instance, attach it to the element, loaded the stream, and finally started playback. . <script> <video> <video> The code and rendered player looked like this Enhancing the Player Experience If basic playback is all that you need for your application, then we’re already there! But sometimes we want to add a bit more to the experience! For that, the Amazon IVS player SDK gives us additional methods and events that we can use to make things shinier. For example, wouldn’t it be cool to add an ‘online/offline’ indicator to the page so that users can quickly see the status of the current stream? What about displaying the latency or resolution of the current stream? What about accessibility? Let’s dig into the player SDK and check out some things that we can do. We won’t look extensively at every single method and event of the SDK, so check out the when you get started with your own application. full player documentation Player Event Listeners We can attach listeners to several events and player states. To do this, we use the method on the instance of the player that we created. For example, to add an ‘online/offline’ indicator, we can add the following HTML (styled with a bit of Bootstrap): addEventListener <span class="badge bg-danger text-white mb-3" id="online-indicator">Offline</span> And attach a listener that calls the method when the player enters a state. playerOnline() PLAYING ivsPlayer.addEventListener(IVSPlayer.PlayerState.PLAYING, playerOnline); The method updates the status indicator to show our users that the stream is online. playerOnline() const playerOnline = () => {
  const indicator = document.getElementById('online-indicator');
  indicator.classList.remove('bg-danger');
  indicator.classList.add('bg-success');
  indicator.innerHTML = 'Online';
} We can also listen for the (paused) and states, and update the indicator to show that the stream is offline. IDLE ENDED ivsPlayer.addEventListener(IVSPlayer.PlayerState.ENDED, playerOffline);
ivsPlayer.addEventListener(IVSPlayer.PlayerState.IDLE, playerOffline); And toggle the status indicator accordingly. const playerOffline = () => {
  const indicator = document.getElementById('online-indicator');
  indicator.classList.add('bg-danger');
  indicator.classList.remove('bg-success');
  indicator.innerHTML = 'Offline';
} It's undocumented, but sometimes I "cheat" and listen for the event which receives a string indicating the destination state. Use at your own risk. Here Be Dragons: STATE_CHANGED <span class="badge bg-info ms-1" id="status">Current State: <i id="current-state"></i></span> ivsPlayer.addEventListener(IVSPlayer.PlayerEventType.STATE_CHANGED, (state) => {
    document.getElementById('current-state').innerHTML = state;
}); Try to toggle playback with the pause button a few times to see the status indicators update in response to the event handlers that we just added. Let’s see how this looks in action! Closed Captions There are additional and values that we can attach listeners to. Another player event is the event. If our live stream contains closed caption data, this event will contain the relevant caption text. Let's update our player to listen for this event and render the caption text from another one of our that contain closed captions. PlayerEventType PlayerState really helpful TEXT_CUE test streams First, update the HTML to create a container to display the captions. We'll use a little Bootstrap magic to place the caption text on top of the player and style it a bit. <div class="position-relative">
    <video id="video-player" controls autoplay playsinline></video>
    <div 
        class="position-relative mx-auto bg-dark bg-opacity-50 rounded text-white text-center fs-3 d-none" 
        style="width: 90%; bottom: 100px;" 
        id="captions">
    </div>
</div> In our handler for the event, we'll hide the container if there is no text to display, show it and populate the text if there is something to display. TEXT_CUE ivsPlayer.addEventListener(IVSPlayer.PlayerEventType.TEXT_CUE, (e) => {
    const caption = e.text;
    const captionsEl = document.getElementById('captions');
    if(caption.length) {
        captionsEl.innerHTML = caption;
        captionsEl.classList.remove('d-none');
    }
    else {
        captionsEl.classList.add('d-none');
        captionsEl.innerHTML = '';
    }
}); If you're not hearing impaired, ignore the fact that the video contains no actual audio that matches the caption text. This is indeed an actual feed with properly embedded captions, but the text is used to illustrate the concept of closed captions at certain points in the video feed. Let's see this one in action! What about real-time captions for live streams with auto-translate? It's possible with AWS Transcribe and Amazon Translate. Check out the . demo on GitHub Player Methods Besides the various events and states that we looked at above, there are several methods that the exposes several methods that give us visibility into various settings and automate playback state. Let’s look at how we can use some of these to display information about the current stream. player Stream Latency and Quality Sometimes we want to display the current latency and resolution of the stream being played. This can enhance user experience, or take action based on a business need. Let’s add some UI elements to display the current stream latency, quality, and frame rate. For the latency value, we’ll use to update the value every 1.5 seconds, and for quality and frame rate, we’ll update the UI in a event handler. setInterval PLAYING setInterval(() => {
    document.getElementById('latency').innerHTML = ivsPlayer.getLiveLatency().toFixed(2);
  }, 1500);

ivsPlayer.addEventListener(IVSPlayer.PlayerState.PLAYING, () => {
    const quality = ivsPlayer.getQuality();
    document.getElementById('quality').innerHTML = quality.name;
    document.getElementById('framerate').innerHTML = quality.framerate;
}); However, the Amazon IVS player can adapt the playback quality based on current network conditions, so the quality can change as the stream is being played! To accommodate, we can listen for the event and update the UI to display the proper value as the stream continues to play. QUALITY_CHANGED ivsPlayer.addEventListener(IVSPlayer.PlayerEventType.QUALITY_CHANGED, (quality) => {
    document.getElementById('quality').innerHTML = quality.name;
}); Manually Setting Quality Even though the player intelligently decides the best quality (for streams), we can also let our viewers manually choose a different quality. Let’s add a button to toggle through the available qualities. STANDARD <button class="btn btn-primary" id="toggle-quality">Toggle Quality</button> A few globals to store the available and current quality values (we'll update these in the and handlers as you'll see in the final demo). PLAYING QUALITY_CHANGED let qualities, currentQuality; And a handler for the button clicks event that will toggle the quality to the next available quality. There is a that ignores calls to when native HTML5 controls are enabled. We'll work around this by temporarily disabling them before we set the quality, and then re-enabling them. Important Note: known issue with the player setQuality() document.getElementById('toggle-quality').addEventListener('click', () => {
    const qualIdx = qualities.findIndex((e) => e.name == currentQuality.name);
    const nextIdx = qualIdx < qualities.length - 1 ? qualIdx + 1 : 0;
    const playerEl = document.getElementById('video-player');
    playerEl.removeAttribute('controls');
    ivsPlayer.setQuality(qualities[nextIdx]);
    playerEl.setAttribute('controls', 'controls');
}); If we wanted to disable the native HTML controls - or just add an external button to control playback - we can add a button: <button class="btn btn-primary" id="toggle-playback">Toggle Playback</button> And use the and methods of the player. play() pause() document.getElementById('toggle-playback').addEventListener('click', () => {
    ivsPlayer.isPaused() ? ivsPlayer.play() : ivsPlayer.pause();
}); That’s a lot of features for this demo, so Notice how the latency, quality, and frame rate update. Also, try manually changing the quality by clicking on the button below the video player and toggling playback with the external button. let’s see it running! Summary We’ve covered a of great stuff in the Amazon IVS player SDK that can help us enhance the playback experience for our users, but we’ve barely scratched the surface of what the player can do. Check out the for all the events, states, and methods that you can use for your production application. In our next post, we’re going to see how to add some interactivity to our stream via custom-timed metadata. ton full player documentation Also published . here

How to Enhance Your Amazon IVS Playback Experience

Showing Video Ads in React Native - Part 2: Android (including Audio Play)

In this article, we are going to describe how to add a video player in your React Native app in order to support the playing of YouTube videos. Video is the present and the future of the Internet, as you can already see through apps such as TikTok, YouTube, Instagram or Facebook. Video support is a feature that makes your app more lively, more interactive and more fun. By the end of this article, you will be able to embed any YouTube video of your choice in a React Native app easily. For you to understand this tutorial you should be familiar with the use of and in React Native. useRef useState To play YouTube videos in React Native, we will be making use of the npm dependency named We will use this library by fully integrating it into an app. react-native-youtube-iframe . Installation You need to install first. Simply run: react-native-webview yarn add react-native-webview

or

npm install react-native-webview then install react-native-youtube-iframe: yarn add react-native-youtube-iframe

or 

npm install react-native-youtube-iframe Usage React ; {View} ; YoutubePlayer ; App = { ( <YoutubePlayer
        height={300}
        play={true}
        videoId={'84WIaK3bl_s'}
      />
    </View> /**
 * Sample React Native App
 * https://github.com/facebook/react-native
 *
 * @format
 * @flow strict-local
 */ import from 'react' import from 'react-native' import from 'react-native-youtube-iframe' const => () return < > View );
}; The required props here are and the of the YouTube video you intend to play in the React Native app. As seen in the app below, we have a Casey Neistat travel vlog on display: height videoId The prop is set to true, so let us take it a step further and control play and pause actions: play React, {useState, useCallback} ; {Button, View, Alert} ; YoutubePlayer ; App = { [playing, setPlaying] = useState( ); togglePlaying = {
    setPlaying( !prev);
  } ( <YoutubePlayer
        height={300}
        play={playing}
        videoId={'84WIaK3bl_s'}
      />
      <Button title={playing ? 'pause' : 'play'} onPress={togglePlaying} />
    </View>
  );
}; /**
 * Sample React Native App
 * https://github.com/facebook/react-native
 *
 * @format
 * @flow strict-local
 */ import from 'react' import from 'react-native' import from 'react-native-youtube-iframe' const => () const false const => () ( ) => prev return < > View Now we have a control to play and pause the YouTube video. It would be nice to add a feature to tell the user that the video is done playing by passing a callback such as the prop provided by the dependency: onChangeState React, {useState} ; {Button, View, Alert} ; YoutubePlayer ; App = { [playing, setPlaying] = useState( ); onStateChange = { (state === ) {
      setPlaying( );
      Alert.alert( );
    }
  } togglePlaying = {
    setPlaying( !prev);
  } ( <YoutubePlayer
        height={300}
        play={playing}
        videoId={'84WIaK3bl_s'}
        onChangeState={onStateChange}
      />
      <Button title={playing ? 'pause' : 'play'} onPress={togglePlaying} />
    </View>
  );
}; /**
 * Sample React Native App
 * https://github.com/facebook/react-native
 *
 * @format
 * @flow strict-local
 */ import from 'react' import from 'react-native' import from 'react-native-youtube-iframe' const => () const false const ( ) => state if 'ended' false 'video has finished playing!' const => () ( ) => prev return < > View Now that we’re done learning the basic usage of this YouTube player dependency, let us go ahead and build a complete control for our video player to play, pause, skip, and mute. React, {useState, useRef} ; {View, Alert, StyleSheet} ; YoutubePlayer ; {Icon} ; App = { [playing, setPlaying] = useState( ); [isMute, setMute] = useState( ); controlRef = useRef(); onStateChange = { (state === ) {
      setPlaying( );
      Alert.alert( );
    } (state !== ) {
      setPlaying( );
    }
  }; togglePlaying = {
    setPlaying( !prev);
  }; seekBackAndForth = { .log( );
    controlRef.current?.getCurrentTime().then( {
      control === ? controlRef.current?.seekTo(currentTime + , )
        : controlRef.current?.seekTo(currentTime - , );
    });
  }; muteVideo = setMute(!isMute); ControlIcon = ( <View style={styles.container}>
      <YoutubePlayer
        height={300}
        ref={controlRef}
        play={playing}
        mute={isMute}
        videoId={'84WIaK3bl_s'}
        onChangeState={onStateChange}
      />
      <View style={styles.controlContainer}>
        <ControlIcon
          onPress={() => seekBackAndForth('rewind')}
          name="skip-previous"
        />
        <ControlIcon
          onPress={togglePlaying}
          name={playing ? 'pause' : 'play-arrow'}
        />
        <ControlIcon
          onPress={() => seekBackAndForth('forward')}
          name="skip-next"
        />
      </View>
      <ControlIcon
        onPress={muteVideo}
        name={isMute ? 'volume-up' : 'volume-off'}
      />
    </View>
  );
};

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: 'darkblue',
  },
  controlContainer: {
    flexDirection: 'row',
    justifyContent: 'space-around',
  },
}); import from 'react' import from 'react-native' import from 'react-native-youtube-iframe' import from 'react-native-elements' const => () const false const false const const ( ) => state if 'ended' false 'video has finished playing!' if 'playing' false const => () ( ) => prev const ( ) => control console 'currentTime' ( ) => currentTime 'forward' 15 true 15 true const => () const ( ) => {name, onPress} );

  return ( < = = = = /> Icon onPress {onPress} name {name} size {40} color "#fff" We have added more custom controls to the original component we already had before and added callbacks to seek forward and backward using the ref. playerRef The mute control is basically managed by the state but it is worthy of note that the dependency provides a method (returns a promise that resolves to true if the video is muted, false if not) to determine if the video is muted or not. isMute isMuted Conclusion Embedding and playing YouTube videos in your React Native app is seamless and a more affordable way of displaying videos in your app, given that YouTube will support the costs of hosting the video itself. The npm dependency we described is really easy to use and is highly customisable, as we have seen in the above snippet where we added forward and rewind controls. Next time you’re looking to add YouTube video support to React Native apps, refer to this tutorial. If you enjoyed the project, please consider sharing the link with your friends and community. Cheers! Previously published at https://www.instamobile.io/react-native-tutorials/play-youtube-videos-react-native/

A Guide to Embedding and Playing YouTube Videos in React Native Apps

I’d an awesome experience when I was in and we’d worked on one problem of public announcement system. So, I’ve decided to write a blog on how to make a simple audio/music streaming server in NodeJS and a simple android app which will stream the real-time audio. By using following code you can make your own local simple music streaming server and that music can be listened on an android client or a browser in real-time. So, let’s open the oven to cook this recipe. Smart India Hackathon Finals Creating a simple Music Streaming Server You can make your own streaming server by using anything but the simplest way I’ve found here is to use the open source software ( Stream What You Hear ). You can check the official site . This application is availabel only for windows and can be downloaded from . You can also use the as well. SWYH here here IceCast The important thing here is that we are not lifting that creepy load of maintaining a buffer and then streaming the audio chunks over the request with the help of some code. We are using these software to handle the weight for us, thus it becomes easy to get a on which an audio is streamed. url Once you’ve installed the follow the steps from here . If everything goes right you’ll end up with the following sreenshot: SWYH Getting-Started Here you can check the as some local address of the server and the route of . To listen the music you have to connect to the same to which the machine with SWYH is connected. You can create a simple hotspot or you may connect to your own network in home. . Now we’re ready to move forward. URL /stream/swyh.mp3 wifi-network This is must that those devices who want to listen the stream should be connected to the same network You can simply just paste the shown by the SWYH to browser and Bingo!! You can listen the music on that device as well. Of course, someone needs to play the music on the machine with SWYH installed. Now you have your streaming server ready and we can build the android app. Don’t worry if you did not understand the above thing so far, it’ll get clear as we go further or you may check the of to get clear understanding. URL documentation SWYH Creating a NodeJS streaming server Let’s suppose that you want to make your streaming public and everyone in the world can listen the awesome playlist you have with Weekend, Linkin-Park, Queen (My favourite one: I want to break free ;-)etc. You can make a simple nodeJS server to the stream which is currently streamed by the software. pipe SWYH To pipe the stream to some different URL we can use . All you have to do is to first install node module. request node module request $ npm install request --save Once you have installed the module, you can use this in your request Express server var express = require('express');    var path = require('path');    var request = require('request');        var app = express()        app.get('/playback.mp3', function(req, res){        //the request module is piping the steam over the get request coming on playback.mp3    request.get('http://<your-swyh-url:56789>/stream/swyh.mp3').pipe(res, function(error){       		console.log(error);       });    });        //here the server is localhost and listening on the port 8000    app.listen(8000,function(){	console.log("Listening on 8000");    }); As you can see we are piping the streaming from one to other i.e from one server to other server. Here, I would like to mention that you can use any link in the function. As an example, you can use as well. URL URL request.get(...) this one //....request.get('http://playerservices.streamtheworld.com/api/livestream-redirect/KUFXFM_SC').pipe(res,function(error){//.... }); And Bingo!! Now you know how to make a simple Music Streaming Server !!! Here half of the recipe gets completed. Baking an android client Creating an android client app for listening the live stream audio is very easy. We are going to use the existing class from android framework. Checkout the description . MediaPlayer here It handles the audio buffering in background and audio can be listened from the speakers of android device. Here is the code inside of an method: onCreate() public class MainActivity extends AppCompatActivity {    //....//declaring the MediaPlayer    MediaPlayer mp;            @Override    protected void onCreate(Bundle savedInstanceState) {    	super.onCreate(savedInstanceState);        setContentView(R.layout.activity_main);        //...        //...        String streamURL = "your-music-streaming-url-whatever";        //Instantiating the MediaPlayer class                mp = new MediaPlayer();                //setting the audio stream type to Streaming music        try{            mp.setAudioStreamType(AudioManager.STREAM_MUSIC);            mp.setDataSource(streamURL);            mp.prepareAsync();        }catch (Exception e){            e.printStackTrace();        }                //catching the error if any        mp.setOnErrorListener((mediaPlayer,what,extra)->{            mediaPlayer.reset();            return false;        });           } Here, we’ve initialised the and the audio stream type is set to . The is set to the we are using to steam the audio/music. MediaPlayer STREAM_MUSIC DataSource URL The interesting thing is the method. This method creates an to the URL and keeps the network out of the . The asynchromously calls the method of our server and in response to request the audi packets are sent. The audio packets are captured and stored in buffer. prepareAsync() asynchronous request MainThread MediaPlayer GET As the buffer is loaded enough to play some bit of music the Media player is prepared to send the sound to speakers. is used to check the above case and we can the music. The below code shows written right below the above code. SetOnPreparedListener play() SetOnPreparedListener mp.setOnPreparedListener((mediaPlayer)->{    	//TODO:use some button to play and pause the music        // you can use this with some button click action as well    	if(playButton.isChecked()){        	mp.start();        }else{        	mp.pause();        }            }); call will play the sound from your speaker and you can enjoy the delightful music. Wow !! mp.start() Now, as we’ve made some mess while making this recipe, we need to place the things right unless we will be facing the tonnes of memory leak in android. In you and method add the following code and you are good to go: onDestroy() onStop() //...    @Override    protected void onDestroy() {        super.onDestroy();        if (mp!=null){            if (mp.isPlaying()){                mp.stop();            }            mp.release();            mp = null;        }     //... Alright, I’m going to listen some Queen and Coldplay. Any queries? Comment section is below ↓ . Genieße die Musik Support me !

Creating a music streaming server and live music playing android client

This post is a follow up to a about building a multiplayer browser game. In this techsploration, I’m going to quickly brush over how latency can affect your game and how to combat that. I will briefly discuss a couple of game frameworks, including one I built at , and how to incorporate sound into your game. post I made a while ago BrickHack3 Latency and Laaaaaaaaaaaaaaaaaaaaaaag So firstly, what is latency? Well, if you’ve played any online game before, you might have experienced that phenomenon where you click or try to perform an action, and the nothing happens in the game until a bit later. Typically known as “lag”, this is incredibly frustrating to deal with for real time games like multiplayer shooters. Latency occurs simply because of the physical distance between your computer and the server you’re connected to. Remember how in we talked about authoritative server determination? That’s what causes the lag since it takes time for your input to be sent to the server, verified, and sent back. part one has fantastic resources and explanations on why this occurs and how to deal with it, and I will be linking lots of resources from his site. http://gabrielgambetta.com A single client-server interaction (image from ) gabrielgambetta.com To combat lag, I’m going to introduce an idea called client prediction/extrapolation. This concept basically involves playing the animation before an action on the client side BEFORE it has been acknowledged by the server to emulate seamless gameplay. The client is basically predicting the state of the server after the acknowledgement. Especially for player movement, this becomes easy to implement if you have a deterministic model for the world. If your game world is governed by predictable and calculated physics, then the client side can make educated assumptions that its input is valid so that the player move animation can begin before the acknowledgement from the server has been received. Client prediction (image from ) gabrielgambetta.com Aside from these awesome diagrams, Gabriel Gambetta’s site has a lot of cool visualizations of how this works and an explanation of some of the problems with this as well. . Since this post is mostly for introducing the idea in the abstract, I highly recommend that you check out his as well if you’d like to implement this in your own code. Definitely check out his live demo sample code incheon.gg The homepage to incheon.gg In the comments of , recommended the framework to me as a way to abstract away most of the problems that I discussed in the first part of this article. This framework is pretty cool and allows for games with discrete and continuous physics, all while handling most of the client-server synchronization logic. I’ve been checking it out and playing with their sample code and I highly recommend using this framework as a start if you don’t want to implement the network code yourself. It is extremely well documented and easy to read. How to Build a Multiplayer Game (part one) Opherv incheon.gg Granted, it was a little difficult to get started (mostly since I had to learn ES6 style classes) but since its such a dense topic with a lot of great discussion points I’ll make another post soon on how I explored the framework and what I made with it. (But huge shoutout to for linking me to this!) Opherv Writing my own game framework at BrickHack3 If you don’t care too much about network lag and you want to try customizing and writing everything including the physics, sound, and animation, you can also check out the . game code that I use Karl Coehlo (left), me (center), Dan Giaime (right) at BrickHack3 I participated in at the Rochester Institute of Technology this weekend, and since my team submitted a ( ), I actually spent some time writing to build the multiplayer game with. BrickHack3 multiplayer game we won the Best Game Award my own framework I build multiplayer games a lot and over the years I’ve recycled a lot of the code. This framework is simply a culmination of what I’ve learned over the years. Unlike , is much more tailored to the type of open world multiplayer games I like to build and doesn’t have any of the aforementioned networking functionality built in. It’s geared more for people who want to learn about game architecture by writing the code for every part themselves. incheon.gg my framework While it’s still a work in progress, works much closer to the node.js architecture that powers it and allows for more of it to be customized. If you’re a game dev beginner or node.js beginner and you just came from , then I’d probably recommend you take a look at this code and tinker with it to understand what it does. my framework part one . This repository contains a refactored, commented, and cleaned up version of the mockup we built in . In the next section, I’ll explain each part of this framework in detail. I suggest cloning the repository if you’d like to follow along. Here’s a link to the GitHub repository part one git clone https://github.com/omgimanerd/game-framework Files included in the game framework Let’s start with , the bread and butter of any node.js project. The main dependencies I have are , , , , and . The only ones absolutely necessary to this project are socket.io, and hashmap though. morgan is a just a useful logging tool, express is a widely used middleware framework, and pug is a template engine, but if you wanted to, you could very easily swap them out for something you’re more comfortable with. The hashmap package is used to map each client’s socket ID to their Player instance, while socket.io is needed of course to power the real-time communication. package.json express hashmap morgan pug socket.io Next is , which contains two client side dependencies, and . Neither is really necessary, but makes your life easier, and is that powers the sound for the game. I’ll discuss how I use later. bower.json jquery howler.js jquery howler.js a cool library howler.js The “lib” folder contains the server side files that handle and store the state of the game and its entities. and are that encapsulate an entity with basic physics and a circular/spherical hitbox. If you wanted to get ambitious, you could implement more elaborate physics, gravity, hitbox meshes, etc into the class. Entity2D.js Entity3D.js ES5 style classes Entity2D.prototype.update = function(deltaTime) {var currentTime = (new Date()).getTime();if (deltaTime) {this.deltaTime = deltaTime;} else if (this.lastUpdateTime === 0) {this.deltaTime = 0;} else {this.deltaTime = (currentTime - this.lastUpdateTime) / 1000;}for (var i = 0; i < DIMENSIONS; ++i) {this.position[i] += this.velocity[i] * this.deltaTime;this.velocity[i] += this.acceleration[i] * this.deltaTime;this.acceleration[i] = 0;}this.lastUpdateTime = currentTime;}; Note how we implemented the framerate independent updating discussed in here. Updates to the position and velocity are done using a deltaTime so that we get consistent behavior. is just an extension of and simply handles user input on top of the basic physics for the purpose of the mockup demo. part one Player.js Entity2D.js is a bit more interesting. Game.js function Game() {this.clients = new HashMap();this.players = new HashMap();} On top of this basic constructor, we have methods that facilitate the connecting and disconnecting of players. Essentially all this class does is handle the updating and broadcasting of the server state. Game.prototype.update = function() {var players = this.getPlayers();for (var i = 0; i < players.length; ++i) {players[i].update();}}; Game.prototype.sendState = function() {var ids = this.clients.keys();for (var i = 0; i < ids.length; ++i) {this.clients.get(ids[i]).emit('update', {self: this.players.get(ids[i]),players: this.players.values().filter((player) => player.id != ids[i])});}}; Game.prototype.update() simply updates every entity in the game, and Game.prototype.sendState() broadcasts the game state to every client connected to the server. The only interesting thing to note (and this is specific to my implementation) is that we filter out the currently connected player and send them separately. You could implement this your own way however. That’s just the way I chose to do it to since it makes my life easier on the client side. Moving on to the “public” directory, this folder contains all the statically served client-side JavaScript files. Remember how we mentioned that it was a good idea to refactor stuff in ? This is just one way of doing it. Building a set of modules that each specialize in handling a specific part of the functionality is always a good idea and good software design in general. part one , given a HTML5 canvas context object, will handle the drawing of all the game sprites onto it. The client side uses to run a game loop on the client side for sending user input to the game server as well as rendering the received game states. Drawing.js Game.js window.requestAnimationFrame() Game.prototype.animate = function() {this.animationFrameId = window.requestAnimationFrame(Util.bind(this, this.update));}; Game.prototype.update = function() {if (this.selfPlayer) {// Emits an event for the containing the player's input.this.socket.emit('player-action', {keyboardState: {left: Input.LEFT,right: Input.RIGHT,up: Input.UP,down: Input.DOWN}});// Draws the state of the game onto the canvas.this.draw();}this.animate();}; This snippet shows a bit of how that functionality works. Here’s a if you don’t know what it does. In case you were wondering, Util.bind() creates a function that binds the context of the Game object to the update() function so that it can be called by requestAnimationFrame(). It’s a nitty hack that goes into the technicalities of JavaScript, so I won’t really discuss that since you can easily achieve the same thing with an anonymous function. link to the requestAnimationFrame documentation is a file I reuse very commonly in my games (with some variation). It binds the necessary event handlers to track user keyboard/mouse input and stores them for easy access. By abstracting away this functionality and keeping it contained in a single class, I don’t have to worry about fetching user input anywhere else. Input.js Although isn’t used in the mockup demo, I’ll explain it quickly here. This file wraps some of the functionality of the amazing library , which I use to play sounds in my games. Upon initialization, it creates Howl objects for every sound that will be used in the game, which can then be played using Sound.prototype.play(). The way I have it implemented, all your sound files must be stored in a folder called “sound” inside the public directory, but this can easily be changed and tinkered with however you see fit. I highly recommend looking through the . Sound.js Howler.js howler.js documentation Moving on, the “shared” directory only contains one file, . Util.js is another one of those files that I recycle frequently between my projects. It contains a variety of useful utility functions that are used on both the client and server side. The “shared” folder is served statically so that I can include the script from an HTML file and require() it from the server side wherever I need. Feel free to relocate this file if you wish; this is just the organization that I found worked for me. Util.js Another way I use the “shared” folder is to store game constants that need to be accessed by both the server and client. For example, I’ll have a class that looks like this: function Constants() {} Constants.PLAYER_HITBOX = 10; Constants.WORLD_SIZE = 2500; if (typeof(module) === 'object') {module.exports = Constants;} else {window.Util = Util;} This allows the class to be handily loaded into the client or server side. The “views” folder is relatively uninteresting and contains the template for the mockup demo. doctype html htmlheadtitle Game!bodycanvas(id='canvas' width='800px' height='600px')script(src='/socket.io/socket.io.js')script(src='/public/bower/jquery/dist/jquery.min.js')script(src='/shared/Util.js')script(src='/public/js/game/Drawing.js')script(src='/public/js/game/Game.js')script(src='/public/js/game/Input.js')script(src='/public/js/game/Sound.js')script(src='/public/js/client.js') I use the , but you could easily plug in any template of your choice. pug templating engine And finally, we have in the root directory. This file is a pretty standard node.js server using the . There are two important snippets to take note of though. server.js express middleware framework const FPS = 60; io.on('connection', (socket) => {socket.on('player-join', () => {game.addNewPlayer(socket);}); socket.on('player-action', (data) => {game.updatePlayerOnInput(socket.id, data);}); socket.on('disconnect', () => {game.removePlayer(socket.id);})}); setInterval(() => {game.update();game.sendState();}, 1000 / FPS); The socket event handlers were covered in , this is the refactored and cleaned up implementation, where we take advantage of the methods we defined in the from earlier. The setInterval() game loop simply runs the game updating and state broadcasting over and over at approximately 60 FPS. part one Game class Next Steps From here, I highly suggest you take this framework and tinker with it. Make it your own, write your own code, print it out and burn it, I don’t care. Try upgrading the physics or writing your own animation engine. I hope you learn something from messing around it and I hope you make something cool. If you do make something cool, please share it with me! I’d be super interested in checking out anything you make. That’s all I have for now. Thanks for reading! Please hit the ❤ button down below if you enjoyed this article :) Follow me on Twitter: @omgimanerd

How To Build A Multiplayer Browser Game (Part 2)

Photo credit — SpaceX I can tell already that this won’t be a popular view, since everyone is jumping on the “future of work” bandwagon. There’s an increasingly popular sentiment about the future of work produced by our beloved echo-chamber, and popularized by the use of words like “Uberization”. Yes, it’s true that and while being remote and having a remote-first culture. the internet allows people to be productive without being co-located Yes, it’s true that one of the big hurdles to being a i.e managing biz-dev is being solved by . freelancer marketplace tools Yes, it’s true that the data says that and often do part-time, remote, freelance work, giving rise to the popular gig economy. an increasing number of people have side gigs It is clear that at least some part of the of work will be remote, freelance, and gig based. But not most of it. future These three trends don’t add up to a future where EVERYONE will be remote freelancers, at least for the next 20 years. Here’s why. Physical projects of great magnitude still require in-person teams to maximize execution velocity. (E.g SpaceX) Back in our cave man days, everyone was a freelancer. But then we discovered that working in teams had advantages for progress, sustainability, and likelihood of long-term survival. The same is true for businesses. (E.g Indus valley civilization) Specialization will become increasingly important. Freelancers often evolve to generalize skill sets, while people with only 1 job often evolve to specialize. As “low-hanging” projects get completed at a faster pace, more people with deeper specialization will be required to go from “0 to 1” to put it in valley terms. Familiar freelancer story #1: First you do a few part-time gigs here and there and enjoy the freedom. It’s nice, and you get to keep your own hours. If you do a great job, you suddenly find that you have a lot more work than you anticipated — so maybe you find a buddy to help out. Oops, you’ve just started a consulting firm. Familiar freelancer story #2: You do a few part-time gigs here and there. Then someone happy with your work asks if you’d consider a slightly longer engagement — like a 3 month project. Sure, you say, as long as you can keep doing stuff on the side. No problem, they say. In month 2, you start enjoying yourself and get immersed in the project, enough to see that it’s really going to take 2–3 years to achieve the vision, and it’s impossible to accomplish everything you want in the meager 3 month time span. You like the people there and it seems like the company is taking off. You say “screw it” and jump on the rocketship full-time. Simply because people have more side-gigs now doesn’t mean that they will abandon their main focus. Gig economy verticals will get consolidated by large players.Fragmented freelance / consulting practices will end up being dominated by a market disruptor that consolidates them under one roof.(E.g Redfin disrupting small real-estate businesses.) The line between contractors and employees will continue to be blurred. We already got a preview of this with the Uber employee vs contractor legal battles. And now . The only difference is that employees tend to get more benefits and rights than contractors e.g healthcare, profit-sharing. So if you have a bunch of long term contractors that are monogamous, and you give them some extra benefits to keep them around, are they still contractors? Hello Alfred is doing W-2’s for their Alfreds This is not to say that companies riding these waves like , Fiverr, Gigster, etc. won’t be successful, nor that remote teams like HelpScout and Buffer can’t work (obviously they do) — it’s just that these trends are not all-encompassing, nor will they be dominating forces in the outcome of the world economy. Catalant

Fallacies in the fully-remote, freelancer-only future of work.

Background I have been playing with Elm for a few months now and have gotten to the point where I am starting to feel like I kn0w my way around the language and how to get things done. This has been a very nice feeling. However, one thing that was gnawing at me this whole time was how a component and an overall application should be sized and set up. While this might seem like a trivial detail, and is something that is easily overlooked, I have found this small detail can have profound impacts on the outcome of a project maintained by one or a few people over a long period or built and maintained by a larger team in a short period. In looking through the Elm code examples, there didn’t seem to be an obvious example, so I looked to personal examples and compared to what seemed to be the opinion of others. Step One: Look to what you have already done… Having come from what now feels like an endless stream of angular applications, I will start there. Based on guides from the omnipresent John Papa in the Angular community, best practice seems to have arrived at dividing controllers, services and factories into the tiniest little blocks possible. On the UI front, directives are the way to go, but I have observed less discipline over their sizing than that of factories and controllers. …quite honestly, it’s 2016. We have enormously productive tools, shortcuts, tricks and abstractions for the backend, why is anyone still writing HTML in the front-end? Practically speaking, I have seen and experienced projects that take tiny services, factories and controllers, share them between directives and, as the code base evolves, create really subtle errors and edge cases that are tricky to track down. Also, directives have a nasty tendency to bloat quite a bit over time. However, the thing that frustrates me the most is: quite honestly, it’s 2016. We have enormously productive tools, shortcuts, tricks and abstractions for the backend, why is anyone still writing HTML on the front-end? The fact that anyone not only wants to continue using HTML, but actually thinks it would be an even better idea to randomly interleave Javascript into a soup of HTML tags just seems like salting an open wound to me. To me, Typescript and Angular 2 just feel like a regression back to Java for the web; and that makes me really sad. So that’s been my experience with Angular 1. Now I need to decide if I want to upgrade to 2 or jump ship. With the Angular folks aggressively pushing Typescript, OOP, and increasingly heavy overhead for creating new projects, it feels like the only fun things in Angular 1 have been sucked out. To me, Typescript and Angular 2 just feel like a regression back to Java for the web; and that makes me really sad. Step Two: Consider alternatives… So the two answers to Angular, as far as I can tell, are React and Elm. I looked into React and actually got really excited about this about Functional Components with React stateless functions and Ramda. I read through it, liked what I saw a lot and thought that would be the model. Chopping everything down to microscopic bits of DOM with data flowing down through their respective components seemed like just the way I thought about applications. I was hooked. post Unfortunately, for all of the great ideas coming out of the React community, and there are many, there are two things that worry me: Tooling, libraries, best practices, APIs and even architectures have been churning every quarter for two years straight. While too much innovation is a classy problem to have, JS fatigue is real and worsens exponentially when working across distributed teams. React is as much a discipline as a framework/design/architecture. If anyone on the team isn’t disciplined, things start to get messy. Thus bringing me to Elm… Elm is wonderful. It handles the state issue by minimizing it as much as practical. It handles the “seriously HTML….it’s 2016” issue by generating it through functions on my behalf. It reduces my applications to testable functions. It reduces the risk of refactor-induced errors through a cheerful and helpful compiler. It eliminates type invariants of all persuasions. It even formats my files for me after each save. It has solved so many of my JS pains I could very well do a backflip for joy. Yet despite all that, something didn’t quite feel right. Spiritual guidance on Brannan Street… So I sought out professional help. I talked to the ever-delightful Richard Feldman at an Elm meetup recently in SF. I shared with him the dream of writing stateless components which could be used like “jigsaw pieces” to build up to bigger and bigger pieces and make a website. He kindly listened and provided feedback that completely changed my train of thought about how an application should be architected. “Make the record as large as you need. When it makes you uncomfortable, it may be time to refactor.” This was the opposite of how I interpreted everything I had read about Elm to date. When I read composable stateless components, I thought about a zillion three line functions slowly building up to a website. Turns out Elm can do that too (and quite well as you will see shortly). But that’s not actually the hard part. It’s the reducer and state management part that really matters. Passing state and messages around an Elm application is an area of lively discussion right now, but prevailing wisdom is that there’s no need to cut the application into smaller pieces than required. It is entirely natural to have a full blown page or major component of an Elm application in one elm file; model, update, view and all. Though you certainly can break each of those three pieces apart if you like. So I took this advice while working through a this weekend with this advice in mind. It was fun, natural and reconnected me with one of the major benefits of functional programming I have experienced: functional programming gives you the tools and framework to build a beautiful API for yourself and others. Don’t believe me, just check out this update function (where the real action of an elm app is): lovely free Elm course update : Msg -> Model -> Modelupdate msg model =case msg of-- On new input, update the text in input boxInput name ->{ model | name = name } --On clicking the save button  
    Save ->  
        case (model.playerId) of  
            -- If the user is being edited, IE already has a   
            -- playerId  
            Just playerId ->  
                model  
                    |> updatePlayerNames playerId  
                    |> updateNameInPlays playerId  
                    |> clearInputBox  
                    |> clearPlayerIndex  
                    |> deactivateEditMode

            -- If the user is new, IE doesn't yet have   
            -- a playerId  
            Nothing ->  
                model  
                    |> addNewPlayer  
                    |> clearInputBox  
                    |> clearPlayerIndex  
                    |> deactivateEditMode

    -- On clicking the cancel button  
    Cancel ->  
        model  
            |> clearInputBox  
            |> clearPlayerIndex  
            |> deactivateEditMode

    -- When the edit mode is activated by "pencil button" click  
    Edit player ->  
        model  
            |> putNameInInputBox player.name  
            |> setPlayerIndex player.playerId  
            |> activateEditMode player.playerId

    -- When the two or three point buttons are clicked,   
    -- update scores  
    Score playerId points ->  
        model  
            |> updatePlayerScore playerId points  
            |> appendPlays playerId points

    DeletePlay play ->  
        model  
            |> removePlay play  
            |> updatePlayerScore  
                play.playerId  
                (negate play.points) If that’s not zen, I don’t know what is. That is code fit for human consumption. Code you could show a non-technical manager….or your Mom and they would totally understand it. Perfect. “Oh yeah, when you edit a player, put their name in the input box, set player index and activate edit mode…” . How I learned to stop worrying and just make stuff again… So my lesson from this was…to relax. Elm takes care of the things that have blown you and your team up when your application goes from a POC to production with a host of new features in between. You can reduce each of your DOM-rendering bits into ever smaller and more reusable components, such as this: Chopping your application into microscopic parts is the symptom, not the cure. playerSection : Model -> Html MsgplayerSection model =div[][ playerListHeader, playerListModel model, pointTotal model] pointTotal : Model -> Html MsgpointTotal model =lettotal =List.map .points model.players|> List.suminfooter [][ div [] [ text "Total: " ], div [] [ text <| toString total ]] playerListHeader : Html MsgplayerListHeader =header[][ div [] [ text "Name" ], div [] [ text "Points" ]] playerListModel : Model -> Html MsgplayerListModel model =model.players|> List.sortBy .name|> List.map (domPlayerMaker model)|> ul [] domPlayerMaker : Model -> Player -> Html MsgdomPlayerMaker model player =leteditChecker =ifmodel.editMode== True&& model.editPlayerId== player.playerIdthenclass "edit"elseclass ""inli [][ i[ class "edit", onClick (Edit player)][], div [ editChecker ][ text player.name ], pointButtonMaker 2 player, pointButtonMaker 3 player, div [][ text <| toString player.points ]] pointButtonMaker : Int -> Player -> Html MsgpointButtonMaker i player =button[ type' "button", onClick <| Score player.playerId i][ text <| toString (i) ++ "pt" ] …which is super cool and what made the React article so neat to begin with. However, microscopic DOM functions aren’t really a problem that required an answer. The thing that makes my blood pressure go down is that state is minimized and in one place for each component start to finish and solely the responsibility of that code’s update function. All of the helper functions to build up to your declarative API are able to stay in the file or move to a helper function file; that’s your call. However, functional programming gives you all the tools you need to quickly build up your API and hopefully, others will find that API useful and able to be leveraged in their projects. Most importantly, because all of those functions are pure functions, you no longer need to worry about someone changing an object, a prototype or anything else in that code while you both are using it. Given an x, that function will always produce a y, regardless of who, when, where and in what context that function is called. I realize this is a major push of React in stateless functional components, but I need to stress, that is a recommendation, not a requirement. Even the most disciplined teams cut corners and POCs have a very nasty habit of outliving their usefulness and scaling terrifyingly beyond their intended use. My experience in software development continually has reminded me of two adages: Any corners that can be cut, at some point will be. There’s nothing longer than temporary. Elm removes all of the major stumbling points of JS frameworks I have seen with very little to give up. But as everything is still so new, best practices seem to be more of an oral tradition than anything committed to writing. So I would like to share the thoughts, experiences and conversations I have had with others so that this language and this community of Elm may flourish. Richard’s feedback was the guidance I needed to push forward and feel confident in what I was doing and made me look forward to building bigger and more interesting things. My sincere hope is something I have written or will write here will be equally useful to others and I will continue to write about my experiences with and learnings about Elm going forward. Thanks to James Moore for putting the online and Richard Feldman for listening to me and giving me the confidence to keep building cool things. great free Elm tutorial Code available for your review : . here is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising &sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories

Some thoughts on Elm Development

Stories, News & Mentions about PLAYERSELF

Playerself’s Stories on HackerNoon