Umbrella term for a collection of technologies (e.g., HTML, JavaScript, CSS and DOM) used together to create interactive and animated web sites
POPULARITY
2 episodes with dhtml
9 episodes with dhtml
2 episodes with dhtml
Before Facebook, there was MySpace. People logged into a web page every day to write to friends, show off photos, and play music. Some of the things we still do on social networks. The world had been shifting to personal use of computers since the early days when time sharing systems were used in universities. Then came the Bulletin Board Systems of the 80s. But those were somewhat difficult to use and prone to be taken over by people like the ones who went on to found DefCon and hacking collectives. Then in the 1990s computers and networks started to get easier to use. We got tools like AOL Instant Messenger and a Microsoft knockoff called Messenger. It's different ‘cause it doesn't say Instant. The rise of the World Wide Web meant that people could build their own websites in online communities. We got these online communities like Geocities in 1994, where users could build their own little web page. Some were notes from classes at universities; others how to be better at dressing goth. They tried to sort people by communities they called cities, and then each member got an address number in their community. They grew fast and even went public before being acquired by Yahoo! in 1999. Tripod showed up the year after Geocities came out and got acquired by Yahoo! competitor Lycos in 1998, signaling that portal services in a pre-modern search engine world would be getting into more content to show ads to eyeballs. Angelfire was another that started in 1996 and ended up in the Lycos portfolio as well. More people had more pages and that meant more eyeballs to show ads to. No knowledge of HTML was really required but it did help to know some. The GeoCities idea about communities was a good one. Turns out people liked hanging out with others like themselves online. People liked reading thoughts and ideas and seeing photos if they ever bothered to finish downloading. But forget to bookmark a page and it could be lost in the cyberbits or whatever happened to pages when we weren't looking at them. The concept of six agrees of Kevin Bacon had been rolling around a bit, so Andrew Weinreich got the idea to do something similar to Angelfire and the next year created SixDegrees.com. It was easy to evolve the concept to bookmark pages by making connections on the site. Except to get people into the site and signing up the model appeared to be the flip side: enter real world friends and family and they were invited to join up. Accepted contacts could then post on each others bulletin boards or send messages to one another. We could also see who our connections were connected to, thus allowing us to say “oh I met that person at a party.” Within a few years the web of contacts model was so successful that it had a few million users and was sold for over $100 million. By 2000 it was shut down but had proven there was a model there that could work. Xanga came along the next year as a weblog and social networking site but never made it to the level of success. Classmates.com is still out there as well, having been founded in 1995 to build a web of contacts for finding those friends from high school we lost contact with. Then came Friendster and MySpace in 2003. Friendster came out of the gate faster but faded away quicker. These took the concepts of SixDegrees.com where users invited friends and family but went a little further, allowing people to post on one another boards. MySpace went a little further. They used some of the same concepts Geocities used and allowed people to customize their own web pages. When some people learned HTML to edit their pages, they got the bug to create. And so a new generation of web developers was created as people learned to layout pages and do basic web programming in order to embed files, flash content, change backgrounds, and insert little DHTML or even JavaScript snippets. MySpace was co-founded by Chris DeWolfe, Uber Whitcomb, Josh Berman, and Tom Anderson while working at an incubator or software holding company called eUniverse, which was later renamed to Intermix Media. Brad Greenspan founded that after going to UCLA and then jumping headfirst into the startup universe. He created Entertainment Universe, then raised $2M in capital from Lehman Brothers, another $5M from others and bought a young site called CD Universe, which was selling Compact Disks online. He reverse merged that into an empty public shell company, like a modern SPAC works, and was suddenly the CEO of a public company, expanding into online DVD sales. Remember, these were the days leading up to the dot com bubble. There was a lot of money floating around. They expanded into dating sites and other membership programs. We'd think of monthly member fees as Monthly Recurring Revenue now, but at the time there was so much free stuff on the internet that those most sites just gave it away and built revenue streams on advertising revenues. CDs and DVDs have data on them. Data can be shared. Napster proved how lucrative that could be by then. Maybe that was something eUniverse should get into. DeWolfe created a tool called Sitegeist, which was a site with a little dating, a little instant messaging, and a little hyper localized search. It was just a school project but got him thinking. Then, like millions of us were about to do, he met Tom. Tom was a kid from the valley who'd been tinkering with computers for years, as “Lord Flathead” who'd been busted hacking as a kid before going off to the University of California at Berkeley before coming home to LA to do software QA for an online storage company. The company he worked for got acquired as a depressed asset by eUniverse in 2002, along with Josh Berman. They got matched up with DeWolfe, and saw this crazy Friendster coming out of nowhere and decided to build something like it. They had a domain they weren't using called MySpace.com, which they were going to use for another online storage project. So they grabbed Aber Whitcomb, fired up a ColdFusion IDE and given the other properties eUniverse was sitting on had the expertise to get everything up and running fairly quickly. So they launched MySpace internally first and then had little contests to see who could get the most people to sign up. eUniverse had tens of millions of users on the other properties so they emailed them too. Within two years they had 20 million users and were the centerpiece of the eUniverse portfolio. Wanting in on what the young kids were doing these days, Rupert Murdoch and News Corporation, or NewsCorp for short, picked up the company for $580 Million in cash. It's like an episode of Succession, right? After the acquisition of Myspace by news corporation, Myspace continued its exponential growth. Later in the year, the site started signing up 200,000 new users every day. About a year later, it was registering approx. 320,000 users each day. They localized into different languages and became the biggest website in the US. So they turned on the advertising machine, paying back their purchase price by doing $800 million in revenue back to NewsCorp. MySpace had become the first big social media platform that was always free that allowed users to freely express their minds and thoughts with millions of other users, provided they were 13 years or older. They restricted access to profiles of people younger than 16 years in such a way that they couldn't be viewed by people over 18 years old. That was to keep sexual predators from accessing the profile of a minor. Kids turned out to be a challenge. In 2006, during extensive research the company began detecting and deleting profiles of registered sex offenders which had started showing up on the platform. Myspace partnered with Sentinel Tech Holdings Corporation to build a searchable, national database containing names, physical descriptions, and other identity details known as the Sentinel Safe which allowed them to keep track of over half a million registered sex offenders from U.S. government records. This way they developed the first national database of convicted sex offenders to protect kids on the platform, which they then provided to state attorney generals when the sex offenders tried to use MySpace. Facebook was created in 2004 and Twitter was created in 2006. They picked up market share, but MySpace continued to do well in 2007 then not as well in 2008. By 2009, Facebook surpassed Myspace in the number of unique U.S. visitors. Myspace began a rapid decline and lost members fast. Network effects can disappear as quickly as they are created. They kept the site simple and basic; people would log in, make new friends, and share music, photos, and chat with people. Facebook and Twitter constantly introduced new features for users to explore; this kept the existing users on the site and attracted more users. Then social media companies like twitter began to target users on Myspace. New and more complicated issues kept coming up. Pages were vandalized, there were phishing attacks, malware got posted to the site, and there were outages as the ColdFusion code had been easy to implement but proved harder to hyperscale. In fact, few had needed to scale a site like MySpace had in that era. Not only were users abandoning the platform, but employees at Myspace started to leave. The changes to MySpace's executive ranks went down quicky in June 2009 by a layoff of 37.5% of its workforce reducing, the employees went down from 1,600 to 1,000. Myspace attempted to rebrand itself as primarily a music site to try and gain the audience they lost. They changed the layout to make it look more attractive but continued a quick decline just as Facebook and Twitter were in the midst of a meteoric rise. In 2011 News Corporation sold Myspace to Specific Media and Justin Timberlake for around $35 million. Timberlake wanted to make a platform where fans could go and communicate with their favorite entertainers, listen to new music, watch videos, share music, and connect with others who liked the same things. Like Geocities but for music lovers. They never really managed to turn things around. In 2016, Myspace and its parent company were acquired by Time Inc. and later Time inc. was in turn purchased by the Meredith Corporation. A few months later the news cycle on and about the platform became less positive. A hacker retrieved 427 million Myspace passwords and tried to sell them for $2,800. In 2019, Myspace accidentally deleted over 50 million digital files including photos, songs, and videos during a server migration. Everything up to 2015 was erased. In some ways that's not the worst thing, considering some of the history left on older profiles. MySpace continues to push music today, with shows that include original content, like interviews with artists. It's more of a way for artists to project their craft than a social network. It's featured content, either sponsored by a label or artist, or from artists so popular or with such an intriguing story their label doesn't need to promote them. There are elements of a social network left, but nothing like the other social networks of the day. And there's some beauty in that simplicity. MySpace was always more than just a social networking website; it was the social network that kickstarted the web 2.0 experience we know today. Tom was everyone who joined the networks first friend. So he became the first major social media star. MySpace became the most visited social networking site in the world, often surpassing Google in number of visitors. Then the network effect moved elsewhere, and those who inherited the users analyzed what caused them to move away from MySpace and either through copying features, out innovating, or acquisition, have managed to remain dominant for over a decade. But there's always something else right around the corner. One of the major reasons people abandoned MySpace was to be with those who thought just like them. When Facebook was only available to college kids it had a young appeal. It slowly leaked into the mainstream and my grandmother started typing the word like when I posted pictures of my kid. Because we grew up. They didn't attempt to monetize too early. They remained stable. They didn't spend more than they needed to keep the site going, so never lost control to investors. Meanwhile, MySpace grew to well over a thousand people to support a web property that would take a dozen to support today. Facebook may move fast and break things. But they do so because they saw what happens when we don't.
Jørgen lurer på om han må vaske vannflaska si hver uke Ole Petter hater haterne som hater i kjønnsdebatten Vi undersøker fenomenet møterom-zombier skråååstrek møterom-mangelen Klubbrapporten undersøker hva DHTML er for noe rart Jørgen anbefaler å rydde opp i hvilke subreddits du abonnerer på Ole Petter anbefaler ASMR-koding på YouTubeArild og Yrjar byr på noen banebrytende kodevitser See omnystudio.com/listener for privacy information.
Panel Charles Max Wood Special Guests: Joe Eames Joe is both into JavaScript Jabber and Adventures in Angular. Tune in to My Angular Story Joe Eames to learn more about his journey into getting where he is now. When he was 16, Joe had a class in high school which required him to go to the University of Utah. Everyday he took half day in high school and traveled to the university to attend class. Since he was up there, he thought that he needed a job to earn money for dates and stuff just like any other kids. He worked in a movie theater, but got suspended because he had an argument with his boss. He looked for another job, and landed onto one in the university where he was studying. He did data entry and dBase maintenance. That was his first programming job. When he turned 19 and graduated from high school, Joe served 2 years in LDS mission. When he came back, he worked in a restaurant for 5 weeks, but moved to Portland because of some knee problems. He spent 2 years there. When he came home, he needed a new job. He found a technical job in a computer company which did data entry. He got hired and was assigned in doing wiring and the like. One manager came to his manager asking for one programmer for a project. Since he was available and had a background on programming, he was recommended for the job. He was then handed with FoxPro books, and started reading them as a head start. He bought a couple of JavaScript books back then. Then there came an emergent technology which he found so cool and awesome called DHTML. Some people in his office were doing it, but he was confused about it. He kind of got it, but he didn't really do much with it. For years he has been doing dot net and programming. He got to the point where he wanted to do something different. He enjoyed doing web technology stuff, but he wanted to get heavier into JavaScript. He decided to leave everything and pursued his profound interest for JS. To hear the rest of My Angular Story Joe Eames, download and listen to the entire episode. Get in touch with Joe and learn more about him by following him on Twitter. Don't forget to let Joe know you heard about him on Devchat.tv's Adventures in Angular My Angular Story! Joe on Twitter If you're short on time, here are the highlights of My Angular Story Joe Eames: How did Joe get into programming? (00:45) His journey to JavaScript? (06:15) How Joe came to Angular? (15:47) Experience as JavaScript Jabber panelist? (21:16) The birth of NG conference? (27:11) Joe's current projects? (39:36) Picks: Joe's Costa Vida NG Cruise Charles' Pick: Air BNB
Panel Charles Max Wood Special Guests: Joe Eames Joe is both into JavaScript Jabber and Adventures in Angular. Tune in to My Angular Story Joe Eames to learn more about his journey into getting where he is now. When he was 16, Joe had a class in high school which required him to go to the University of Utah. Everyday he took half day in high school and traveled to the university to attend class. Since he was up there, he thought that he needed a job to earn money for dates and stuff just like any other kids. He worked in a movie theater, but got suspended because he had an argument with his boss. He looked for another job, and landed onto one in the university where he was studying. He did data entry and dBase maintenance. That was his first programming job. When he turned 19 and graduated from high school, Joe served 2 years in LDS mission. When he came back, he worked in a restaurant for 5 weeks, but moved to Portland because of some knee problems. He spent 2 years there. When he came home, he needed a new job. He found a technical job in a computer company which did data entry. He got hired and was assigned in doing wiring and the like. One manager came to his manager asking for one programmer for a project. Since he was available and had a background on programming, he was recommended for the job. He was then handed with FoxPro books, and started reading them as a head start. He bought a couple of JavaScript books back then. Then there came an emergent technology which he found so cool and awesome called DHTML. Some people in his office were doing it, but he was confused about it. He kind of got it, but he didn't really do much with it. For years he has been doing dot net and programming. He got to the point where he wanted to do something different. He enjoyed doing web technology stuff, but he wanted to get heavier into JavaScript. He decided to leave everything and pursued his profound interest for JS. To hear the rest of My Angular Story Joe Eames, download and listen to the entire episode. Get in touch with Joe and learn more about him by following him on Twitter. Don't forget to let Joe know you heard about him on Devchat.tv's Adventures in Angular My Angular Story! Joe on Twitter If you're short on time, here are the highlights of My Angular Story Joe Eames: How did Joe get into programming? (00:45) His journey to JavaScript? (06:15) How Joe came to Angular? (15:47) Experience as JavaScript Jabber panelist? (21:16) The birth of NG conference? (27:11) Joe's current projects? (39:36) Picks: Joe's Costa Vida NG Cruise Charles' Pick: Air BNB
Panel Charles Max Wood Special Guests: Joe Eames Joe is both into JavaScript Jabber and Adventures in Angular. Tune in to My Angular Story Joe Eames to learn more about his journey into getting where he is now. When he was 16, Joe had a class in high school which required him to go to the University of Utah. Everyday he took half day in high school and traveled to the university to attend class. Since he was up there, he thought that he needed a job to earn money for dates and stuff just like any other kids. He worked in a movie theater, but got suspended because he had an argument with his boss. He looked for another job, and landed onto one in the university where he was studying. He did data entry and dBase maintenance. That was his first programming job. When he turned 19 and graduated from high school, Joe served 2 years in LDS mission. When he came back, he worked in a restaurant for 5 weeks, but moved to Portland because of some knee problems. He spent 2 years there. When he came home, he needed a new job. He found a technical job in a computer company which did data entry. He got hired and was assigned in doing wiring and the like. One manager came to his manager asking for one programmer for a project. Since he was available and had a background on programming, he was recommended for the job. He was then handed with FoxPro books, and started reading them as a head start. He bought a couple of JavaScript books back then. Then there came an emergent technology which he found so cool and awesome called DHTML. Some people in his office were doing it, but he was confused about it. He kind of got it, but he didn't really do much with it. For years he has been doing dot net and programming. He got to the point where he wanted to do something different. He enjoyed doing web technology stuff, but he wanted to get heavier into JavaScript. He decided to leave everything and pursued his profound interest for JS. To hear the rest of My Angular Story Joe Eames, download and listen to the entire episode. Get in touch with Joe and learn more about him by following him on Twitter. Don't forget to let Joe know you heard about him on Devchat.tv's Adventures in Angular My Angular Story! Joe on Twitter If you're short on time, here are the highlights of My Angular Story Joe Eames: How did Joe get into programming? (00:45) His journey to JavaScript? (06:15) How Joe came to Angular? (15:47) Experience as JavaScript Jabber panelist? (21:16) The birth of NG conference? (27:11) Joe's current projects? (39:36) Picks: Joe's Costa Vida NG Cruise Charles' Pick: Air BNB
Czwarty odcinek podkastu gotowy, by zabrzmieć w Waszych uszach! Korzystając z okazji, bo dziś Halloween – wskrzesimy wspomnienia oraz pamięć o zapomnianych platformach i technologiach. Do tego święta podchodzimy z przymrużeniem oka i mamy nadzieję, że udało się nam również utrzymać luźny charakter samego nagrania. Jeśli zbytnio "przytetryczyliśmy" – wybaczcie, wiecie gdzie kierować zażalenia, skargi i wnioski. Co by nie padł zarzut, że nic o jabłkach, przypominamy o halloweenowej zabawie zwanej apple bobbingiem. Poniżej kilka wybranych odsyłaczy do stron z rzeczami, o których wspomnieliśmy w kompocie: prezentacja Douglasa Engelbarta – Mother of all Demos moduł Jogeira Liljedahla – Guitar Slinger (YouTube) (MOD) moduł Walkmana (Tora Bernharda Gausena) – Klisje Paa Klisje (YouTube) (MOD) moduł Emaksa (Benniego Pedersena) – Defloration (YouTube) (MOD) moduł Scorpika (Adama Skorupy) – Próba mikrofonu (MOD) moduł Vulture – Anti-Atari song (MOD) Archiwum MODów amigowych klon Protrackera Audio Overload Richarda Bannistera – odtwarzacz muzyczny wspierający MODy (oraz inne formaty "z epoki") Archiwum dem amigowych kanał RetroDemoScene na YouTube z najpopularniejszymi produkcjami na Commodore 64 i Amigę wiki n/t grupy scenowej Slight, w której (między innymi) działał Remek (Rzóg) pierwsze demo grupy Slight Bitter Reality (YouTube) Opus Magnum grupy Slight - Overmind (YouTube) (nie)sławny joystick Atari (wiki) gra Jetpac (wiki) (JavaScript) gra Jet Set Willy (wiki) (JavaScript) gra Lode Runner (wiki) (HTML5) gra H.E.R.O. (wiki) (JavaScript) gra River Raid (wiki) gra Raid over Moscow (wiki) gra Crystal Castles (wiki) gra Pengo (wiki) gra Draconus (wiki) gra Zybex (wiki) gra The Goonies (remake) gra Boulder Dash (wiki) (JavaScript) gra Gyrrus (wiki) (JavaScript) gra Robbo (wiki) gra Wings (wiki) (GOG) gra Cannon Fodder (wiki) (GOG) gra Lemmings (wiki) (DHTML) gra SlamTilt (wiki) gra Moonstone (wiki) język programowania Logo (wiki) (JavaScript) język programowania BASIC (wiki) (JavaScript) edytor tekstu TAG (wiki) archiwum polskich amigowych magazynów dyskowych Fat Magnus archiwum zasobów Atari zbiór archiwalnych numerów czasopisma IKS zbiór archiwalnych numerów magazynu Bajtek jedna z publikacji Marka w serwisie PPA czasopismo Total Amiga, w których wybrane teksty (n-ry 22 i 23) tłumaczył Marek magazyn Świat Gier Komputerowych, w którym pojawiło się kilka recenzji Marka (kwiecień - sierpień 1993) mikrokomputer ZX Spectrum mikrokomputer Bosman 8 mikrokomputer Amstrad-Schneider CPC mikrokomputer Unipolbrit mikrokomputer Atari 800XL mikrokomputer Amiga 500 Po nagraniu wyszło na jaw, że pamięć bywa zawodna i kilka błędów popełniliśmy. Za to powyższa lista jest w 100% wolna od chochlików. Nasz podcast znajdziecie w iTunes (link), możecie też dodać do swojego ulubionego czytnika RSS (link) lub przesłuchać bezpośrednio w przeglądarce (link). Zapraszamy do kontaktu na Twitterze: Remek Rychlewski @RZoG. Marek Telecki @mantis30. Natomiast całe przedsięwzięcie firmuje konto @ApplejuicePl. Jesteśmy również dostępni dla Was pod adresem e-mail kompot[at]applejuice.pl
Kris Van Houten: @krivaten | krivaten.com | Q2 Show Notes: 00:55 - Kris' Interest and Passion for Accessibility 06:07 - Using Ember for Accessibility: Pattern Adoption 10:13 - Context Switch Awareness and Managing Focus 12:08 - Asynchrony and Desired Interaction 14:04 - Building a Form Input Component 19:05 - Things That Are Hard to Catch 22:41 - Assistive Browsers? 28:17 - Making Things Accessible From the Start Resources: Building for Accessibility by Nathan Hammond @ Wicked Good Ember 2015 The A11y Project: Web Accessibility Checklist WCAG 2.0 checklists Why Don't Screen Readers Always Read What's on the Screen? Part 1: Punctuation and Typographic Symbols Mozilla Accessibility Kris' Blog Post Series on Accessibility: Part 1: What is accessibility and why should we care? Part 2: A Primer on Accessibility Part 3: Getting Our Apps Ready for Accessibility Part 4: Building an Accessible Icon Component in Ember Part 5: Building an Accessible Input Component in Ember Part 6: Building an Accessible Alert Component in Ember Part 7: Building an Accessible Numbers Component in Ember Part 8: Building an Accessible Currency Component in Ember Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 72. My name is Charles Lowell, a developer here at The Frontside and podcast host-in-training. With me today is Wil. WIL: Hello. CHARLES: Hey, Wil. Today, we're going to be talking about accessibility in single page applications with Kris Van Houten who is a developer at Q2. Hey, Kris. Thank you for coming on the show. Today, we're going to talk about something that I know a lot of people's minds here and probably elsewhere on the internet, it's a topic that's getting a lot more attention, which is a good thing and that's accessibility. We're going to explore the niche of accessibility as it applies to single page applications. Now, you're a frontend developer at Q2, what initially got you interested in and passionate about accessibility in general? KRIS: I honestly feel my path to passion in this area has been a little bit unorthodox in a number of ways. I basically started out in total apathy of this topic and over the last year, it has turned into a genuine interest of mine. About three years ago, I remember listening to an episode of ShopTalk Show with Dave Rupert and Chris Coyier and they kind of went on this large rant about accessibility and why more developers need to be concerned and compassion about it. Dave Rupert was talking about his contributions to the accessibility project and I'm sitting back and thinking to myself and this is back then, obviously, "Why would anyone who is blind want to use anything that I'm working on." I basically balked at the idea and disregarded it entirely. At that time, I was just getting my feet wet with Ember working on an application with a company here in Cincinnati and we had these conversations about, "I notice that we put this action or a clickable event on a div element, should we not be doing that? Is it that not something that we should be doing?" I remember sitting back and having this conversation and saying, "The ads been crawled by SEO and Ember isn't yelling at us for doing it. It still works fine so what the heck? Let's just go with it." Basically, every single app that come into since then has basically adopted that same mindset even before I joined the team so I know it's not just me who is thinking this. A lot of developers that have been exercising the same way of doing their code. CHARLES: Right, it's the path of least resistance. Everybody's got a job to do. Everybody's got features to deliver so that practice can be very easily self-perpetuating, right? KRIS: Exactly and I think a lot of developers just don't understand the semantic difference between a div or a label or a button or a link and how browsers can actually treat these difference HTML attributes or HTML tags differently because of how assistive technology can utilize them for per person's benefit. That's where I was a little over a year ago basically. When I first started at Q2, that first week, I got pulled into a discussion about design patterns which is another passion of mine and somehow, that turned into me joining a group that was to establish to figure out how to tackle the task of making our large app accessible. Basically, we had a company come in, audit our application and we got a big fat F for accessibility so it's something that we said, "We need to start tackling this problem." Being that, I just started at the company that week, I was going to tell them no but internally, I was panicking and saying, "I got to figure out what is this whole accessibility thing is and why it's important." I started looking for books, articles on the topic and trying to basically flood myself with information. Two things that really transformed my way of thinking was actually a talk given by Nathan Hammond at that Wicked Good Ember in 2015, where he shows an example of building an application without accessibility in mind so basically, doing what I was doing before which is we're adding actions to div tags, we're not really caring about semantic HTML, we're just making the feature or the application work. But then what he does, which I think is super powerful is he pulled up a colleague of his who is blind and had him try to use the application. He just goes through and you can see the struggle and he's actually vocalizing and talking about where he's [inaudible] with this application. Long story short, Nathan comes back up and makes a few adjustments. DHTML has [inaudible] up again and it's night and day difference just by changing the markup and by dropping in the Ember A11y add-on which helps with focusing the browser in certain areas of the content. He's able to totally transform how's individuals able to use the app. For me, that was a super powerful to come in and see that and see someone actually struggle with a website that they were trying to use. I think, [inaudible] where I always saw accessibility was it will only affects people who can't see and I think that's the other area where I've really started to have that paradigm shift was when I realized that this isn't just people who can't see. It's for people who have motor difficulties, who can't use a mouse and how to use a keyboard instead. People who have various vision issues, whether that's cataracts, colorblindness, glaucoma, dyslexia, some in these effects, not just DHTML but also affects color contrast, the fonts that we're using that impacts every area of application design and development and that's where I started to realize that that was where the paradigm shift happened in my mind where I started thinking to myself we really need to start talking about this more and getting other developers on board in general on this. CHARLES: It can be intimidating, especially when it feels like on a single page application, your divs have to do more, so to speak in the sense that it feels that your HTML is fatter. It's not just a thin layer but your HTML is actually part of the UI. KRIS: Exactly, yeah. CHARLES: When it comes to having this paradigmatic shift that you're describing, when you're looking at your single page applications, are there any insights into the general structure of the application that you feel like you've gained that are foundational, they kind of transcend accessibility? I guess, what I'm saying is, is there any way that you become like a better developer or been able to recognize foundational patterns because of having these insights surrounding accessibility? KRIS: I've been working with Ember for about three or four years now, basically since it was still in beta. Over the last several years, I have started to accumulate a lot of knowledge as to how we can utilize Ember to do a lot of the heavy lifting for us. When I started getting more passionate about the area of accessibility, first question that came into my mind are how can we use Ember to do some of the heavy lifting for us. For example, some of the things that I had done was go through and start working on developing a couple of components that basically cover a lot of things that I find ourselves doing [inaudible] a lot. Whether that might be a component to just plain icon on a page or a component to display input on a page. What we're able to do is using Ember, we can say, "Here's the icon I want to display but if I don't happen to pass in an aria-label attribute, for example. The component will add the 'aria-hidden=true' for me. Being able to really utilize the power of Ember to do some of that stuff for us on the back side of things, I guess you could say it magically. CHARLES: Let me stop you there for a second and unpack that example. What you're saying is, if I'm going to put an input on the page, if I actually don't assign an ARIA role, it's going to hide it from me? KRIS: No. I was thinking of an icon components, say if I'm using Font Awesome, for example and I want this with the trash icon so I wrote a component for our specific icon library that we're using. We pass in the icon that we want to display, again that could be the trash icon and we can also pass in an aria-label attribute to add a label to that span that will be read to the user. But if we don't pass that attribute in, the component will automatically add the 'aria-hidden=true' attribute for us so basically it skips over it. CHARLES: Yes so it won't be just garbage for a screen reader or someone navigating with a keyboard. WIL: Yeah, otherwise the screen reader tries to read the content of the icon CSS which is just the Unicode. CHARLES: Right. KRIS: Yeah. What we really is trying to figure out and what I've spent a lot of my time, especially in writing my blog series on this was while we are using React or Vue or Angular or Ember or whatever, how can we utilize the power of the single page application frameworks to do some of that heavy lifting for us in the background without us needing to explicitly define everything. I'd say, especially when you work on a large team like what I work on currently, we can't expect everybody to be extremely well-versed in the area of accessibility so if we can do some of the work for them and just encourage them to adopt these components in their daily workflow, it does some of the work for us. That's what we're working on and talking a lot about at Q2 is basically this pattern adoption. CHARLES: Right so it sounds like to kind of paraphrase, whether you're working in any framework most of them have this concept of components so really leaning hard on that idea to make components at the very granular level aware of their own accessibility. Is that fair to say? KRIS: Yeah, obviously there's more I'm sure as we go for the conversation about some of the things that I've tackled in this area but long story short, being able to utilize and recognize, you have this extremely powerful JavaScript framework at your disposal to do some of work for you so why not equip to do just that. CHARLES: Yeah. I guess that falls into my next question, which is there are component level concerns and if there are other component level concerns, I definitely want to hear about them but what immediately leaps to mind is there are also cross-cutting concerns of any single page application, what's the state of your URL and if you're using a router. Some of the content on the page is going to be changing and others isn't like how do you cope with that? What are the cross-cutting concerns of an application that span components and then how do you cope with them? KRIS: I think one thing that comes to mind as you're talking is the whole area of context switch awareness. If I click a link, if I go from the home page of an application to my profile page, how does a screen reader know that that content has now changed to present this new information to the user? I know what we were able to do was we were able to drop in the focusing out with component that's put out by the Ember accessibility team, which basically whenever we render to an outlet, that's utilizing this focusing outlet component, it will focus the browser to that main area and start presenting that information back to the users. One area that was at the top of our list as we start tackling accessibility was we need to figure out this whole context switch awareness thing because -- this is back then obviously when we first got started -- back then there was no way for a user to know when the page changed so they would basically be sitting there, waiting for any kind of feedback or whatsoever to be presented back to them and it just wasn't happening. I would say, managing focus is probably one of the top level concerns when it comes to single page applications because it's a single page application so if you click a link, the page isn't completely refreshing, prompting the screen reader to present the information back to user. That's one of the key areas that I think of. CHARLES: What about things like asynchrony because a lot of times, these context switches are not boom-boom, one-two. The content on which you want to focus isn't available yet. Usually, the analog from a visual UI would be a loading spinner or a progress bar. How do you deal with those to say, "Your content is not quite ready. If you're made to wait it's because we want your content to be of the highest quality." KRIS: Sure, yeah. We were able to drop in the focusing outlet components in our application and it took care of a good chunk of the work but it seems like in our application, we're doing something that might not be as conventional as the rest of the Ember community would like them to be so we might not use the model hook as we should. It's hard for the page to know when the contents actually ready, when it's been rendered to the DOM to present back to the user. One thing that I'm currently trying to tackle right now, to figure out how we can remedy that problem. I probably say, honestly that's the challenge I'm working on right now. I don't have a solid answer to that one at the moment. CHARLES: Irrespective of how it plugs into the tool that you're using, what would just be the desired interaction there, regardless of how you make it work? KRIS: I guess, conceptually what I'd be thinking about is how can we notify the user we're loading content right now and whether that we have an alert box that has the ARIA alerts, basically attributes set on it, that we could pass in new, basically notifications to it to let the user know, "Loading content. Please wait," and then once that content resolves, focus them on that main outlet where the content has been displayed to read that content back to the user. That's how we're trying to think about tackling this issue but we haven't have a time to implement it to see how it's going to work across all the different avenues of application. CHARLES: I did want to come back at the component level. are there any other ways that you can lean on Ember or lean on React or lean on Vue, if you're using a component or in framework, just talk a little bit more about how you use those to unlock your application and make it more accessible. KRIS: One thing I can think of is a way that we can enforce better usage of the framework that we're using is one that comes to mind is a component that I worked out in the blog series that I wrote was building a form input component. Especially, when you're trying to write an accessible app, I think about how can we enforce certain patterns when other developers come in later on and want to add a field to a form or use this component somewhere else in the application. What are some ways that we can enforce that they're doing everything, using the component correctly so that way it renders accessible mark up? What I tinkered around with and we actually just landed in our application is basically a form group component to where we pass in, obviously the value that the input is bound to. But we also pass in a label that is tied to the input and whenever you hit save and the app goes to refresh, if you don't pass the label, there's an assert statement that basically fires up an error into the console and lets you know, "You're trying to use this component, you need to pass into label attribute for the purposes of accessibility and here's the instructions on how to do it." We've been kind of toying around with this idea of enforcing patterns because again, we have several dozen developers at Q2 that are working on this stuff and they're not all wizards when it comes to accessibility but how can we gradually start getting them to the place where they're adopting these patterns and best practices. I'd say, doing things like that, we are enforcing patterns in the usage of the components as well is really a key. One thing that we implement it in our testing framework is the use of a Deque Labs' aXe engine to basically go through, we can pass it a chunk of HTML and it will give us any suggestions that it has to make that content more accessible. We're using that in our test library right now, in our test build and encouraging developers as they write new components, as they go in and modify components to throw new snippets in to make sure that the content that's being spit out here is accessible and then submit your PR again. Just trying to be more hands on in that way. CHARLES: So you actually running a GitHub agent or something that's actually in the same vein as your test suite or if you're taking like snapshotting with Percy for doing visual diff so you're actually running a third check, which is an accessibility check? KRIS: Right now, we were able to land the aXe engine into our test build a couple months back so we're just slowly incrementing that over time. We have a couple challenges in the way of getting Percy implemented but that is in our list of goals to have that running as well. But one thing that I really like about aXe engine in particular is that if your check fails, it refines improvements that you should be making. The nice thing about it is also spits out a link to a page on Deque Labs website. They give an explanation of what have found and basically educates your developers for you. To me, I think that's huge because again, we can't educate every single developer and expect them to be pros at this but we can utilize tooling like the aXe engine or the [inaudible] Chrome extensions or stuff like that to do some education for us. As we work towards automating this further and further by using the aXe engine in our development side of things or using Percy on the test build as well. See, there's all kinds of stuff you can do but that's where we are right now. CHARLES: I really like that idea because in comparison with what we talked about at the top of the show, about how there's this path of least resistance that developers will follow quite naturally and quite rationally, which can lead to not accessible applications. It sounds to me like what you're doing is a establishing the same path of least resistance but having that path guide you towards accessible applications and saying, "This path of least resistance thing, it can be an asset or a liability so we might as well make it an asset." KRIS: Yeah, for sure. We sit down once a week and we talk about whatever challenges we're trying to work through in terms of accessibility. We have a weekly meeting where we sit down and talk about it. I thought one of the key topics to those conversations is how do we get the other developers that are not in these meetings more aware, more informed and more up to speed with this that they care about it, that they're working on it and it's part of their inner dialogue as they're writing out new features that are going to be deployed out to our clients. Lots of challenges there. CHARLES: Yeah. We've talked about some of these problems that you catch, you're actually writing some assertions there on the test build so you'll actually fail if there's certain requirements that aren't met but what are the things that are more intangible? How do those come up in terms of accessibility? What are the things that you can't catch through automated testing? KRIS: Right now, some of things that we're having a hard time testing which Percy will help once we get that implemented is contrast ratios and stuff like that. That's one of the key things that comes to mind for me when I think of the things that are a little hard to catch. I think another thing that's hard to catch, especially at the aXe engine and stuff like that, won't necessarily catch is the flow of your dialogue. When I turn on a screen reader and it starts reading back this page and content to me, sure we can make it so that it doesn't read out the icons character code and a lot of stuff. It presents the information we want back to us but I think, having that information presented back to the user in a way that's legible, that makes sense to them is probably one of the bigger challenges that I've been working on a little bit. One that comes to my mind is like the reading of currencies or numbers. One thing that I found way helpful was Deque put out a very thorough article on how the different screen reader like JAWS, NVDA, Apple's VoiceOver, how they read different types of punctuation, different types of graphics symbols, how they read [inaudible], $123.50, what does a screen reader actually read back to you. That's where I've actually been spending so much of time lately is building on some components that instead of reading back what the streaming will read back by default, which should be, "Dollar sign, one-two-three-five-zero," having actually read back, "One hundred twenty-three dollars and fifty cents," so basically, writing a series of components, I would do some of that, again heavy-lifting force, in that way, our developers don't have to go in and manually add-ons aria-labels obviously. That's been a nice little challenge where something that's we are working on just testing right now and making sure it works right if there is any downsides to doing this but I want a person using a screen reader or other types of assistive technology to hear the information as I'm thinking about it. When I see $123.50, I'm thinking in my head that's, "One hundred twenty-three dollars and fifty cents," not in single digits one right after the other. Those are things that a lot of the automated software isn't catching. It's not catching like, "Your grammar is bad," or, "This isn't making any sense to me." It is catching like are you passing in or applying the attributes to HTML elements that you should be. Are you using semantic structure in your headings and stuff like that?" I think that's one of the areas where developer is need to get their hand dirty, turn on the a screen reader or use any array of different voice-over tools to actually listen to the content being present back to them to see how it's presented. CHARLES: Yeah, it's almost a difference between a syntax error versus a runtime error like we've got a lot tools that can catch the syntax errors and you can put those in and catch where you have something that's malformed but some sentences can be perfectly formed but make no sense and it takes a human set of eyes to make sure if that content is coherent. One of the things that if you're going to ship applications to people, you need to be able to try and measure as closely as possible the environments in which the people will be using your software so you can actually have an accurate measure of whether it works or not. For example, in the Ember world lately in the stuff that we've been doing with acceptance testing in React, we admit people are going to be using a multiplicity of browsers to access this application so it's very typical to use Testem or use Karma to fire up five different browsers, which if you're using BrowserStack, you can do fifty. You know, people are going to be using IE8.1 on Edge or on a Surface. They're going to be using Safari. They're going to be using Chrome and those often surface those issues but I feel like there's no access to the actual screen reader and assistive technologies to be able to make real assertions against those things. I imagine that it would be cool if there was some way that in Testem or in Karma, you could have one of your browsers be like an assistive browser that you could actually assert, I want to assert that it read it as, "One hundred fifty-three dollars and twenty-five cents," and is that on the horizon? Is that even possible? But it seems like something that we have to shoot for if we actually want to measure that these things are working if we actually want to capture data points. KRIS: Yeah, I totally agree. If you look at the documentation on W3 for how these different HTML attributes should be treated by the browser or by the assistive technology, long story short is this is not how -- in several cases -- certain screen readers are presenting the information back to you. It's not how it's treating the content. That's again, one of the areas I thought was way interesting about that. Deque article on punctuation and typographic symbols, which is like we should expect that this software is operating at this level to present this information back to user in such a way where it understands what the dollar symbol in front of a series of numbers means but it just isn't there yet. There's still work to be done. I'm hopeful for the day where our screen readers are a lot more powerful in that capacity. One that makes me a lot more hopeful about that is I don't know if it's just because I've been more interested about this over the last year but it does seem like I'm seeing a lot more people talk about accessibility. I'm seeing Apple putting out videos, talking about the efforts that they're making to make their software more accessible. It does give me hope that there's a lot more visibility on this now. There's a lot more people fighting for this cause to cause these companies to come back and say, "We're going to put more effort into this. We not just going to make a standard screen reader and ship it and just leave it there for five years and no one was going to touch it," but, "We're going to start making improvements." One thing that I did notice just over the last couple months even was that out of nowhere, we use Apple VoiceOver in Chrome, which isn't typically how people use it. They typically use it with Safari. But if you use in Chrome, it will actually read back to you as, "One hundred twenty-three dollars and fifty cents." When I came across that, I was kind of dumbfounded but then I was thinking to myself, the vast majority of people who are using screen readers aren't using this browser but that's really interesting that they're doing this now. I dream of that day where we can basically run a series of mark up through in a test or into a function and basically have to spit back, here's how screen readers going to present this back to you. I'm hopeful for that day. CHARLES: I'm wondering now like why don't major browser vendors, why is this not just a piece of a puzzle that comes when I download Firefox. Firefox has access to my speakers, why isn't there a web standard for how screen readers will treat content? Maybe there's an effort under way. KRIS: I sure hope so. Looking through documentation, we know how things are supposed to work, how we've agreed that they should work and now basically, we're just waiting for the different browser vendors and Microsoft and Apple to make the updates to their streaming technology as well as JAWS and NVDA. I'm hopeful that these changes come soon. These are improvements to the interface. CHARLES: Yeah. Any time there's a gap, you can see that's an opportunity for someone -- KRIS: For sure. CHARLES: -- To write some software that has some real impact. I know certainly, I would love to see some way to roll these things into our automated test suites. KRIS: Yeah. I searched for it but with no avail and it's a little bit beyond my knowledge of how to build something of that caliber. I hope someone else does it because I don't know how. [Laughter] CHARLES: Well, maybe in a year, maybe in two years, maybe in 10, although hopefully a lot sooner than that. KRIS: Yeah. I would judge that at the speed of things were going right now, I'm optimistic that we're going to have some much better solutions within the next year or two on this field. Especially of how much I'm seeing people talk about it now, how much it's becoming a part of the regular conversation of web development, application development. I'm really optimistic that we're going to see some strides in this area over the next couple years. CHARLES: Okay. With the time that we have left, I'm going to ask one more question. Kris, there is something that I wanted to ask you, which is let's say that I am a developer who is working on a team that is maybe it's big, maybe it's small. I've got an application or I'm starting an application and I have a desire to make it accessible. How do I establish that path of least resistance? What advice do you have for someone who's just about to take the first step on that journey to make sure that they have the outcome that they're looking for which is the most accessible single page app that they can have? KRIS: I think it's a great question. I would start out that answer by simply saying to encourage you to be somebody who cares enough to speak up and become an evangelist, become an educator and become an enforcer in your workplace for this work. You don't have to be the most knowledgeable person in the world on the topic. God knows I'm not and I still there were people come to me, asking me, "How do I make this feature, make the guidelines, make it accessible to screen readers," but I'm passionate about this topic and I'm interested in learning as much as I can about those. Step one, just being an evangelists for it. Be interested in it, care about it. I'd say, the next thing is just learn more about semantic HTML. I would say from a lot of the things that I've been trying to tackle with the application that I'm working on, just simply writing semantic markup takes care about 80% of my challenges. In just understanding what are the different elements, what are the different tags are for and how screen readers and other assistive technology see those things. To get started, I would say there's beginner, intermediate and advance stuff. I would say go to the accessibility project, which is just A11yProject.com and read through the content there. It's very entry-level. You can probably read through most of the content within an hour or two and really start to get a grasp as to what level of effort you're looking at in terms of your application. Once you get through that, if you still want to learn more, I'd say go over to Mozilla's developer network -- MDN -- and read through their documentation. On the topic, there is a little bit more exhaustive but it's still really easy to read and really easy to grasp. Based on a content they have shared there, I'd say more of an advance level is actually go through all the documentation on the W3. It's a lot more verbose, it covers a lot more of use cases, it has a lot more suggestions and just stuff ready to go over. I'm still working through that information. There's so much of it but I would say that's as a good place to get started with understanding the different attributes, what they're for and just the importance of writing semantic HTML. I would say some definitely good things to start tinkering with to find some of the low-hanging fruit in your application would be to use some of the assessment tools that are already out there. You have the [inaudible] little JavaScript snippet that you can put in your Chrome favorite's bar or you can use the aXe engine or if you even have an aXe Chrome extension that you could pop up in your application to basically give you report on some of the areas that you should be looking to make some improvements. I think it's important to view accessibility kind of like how a lot of bloggers view SEO, is that there's always more work to be done, there's always improvements you can make but the key is to take those first steps and start making those improvements. One of the nice things about the accessibility project and there's a couple other websites out there that have some of the lists, they basically have a checklist for you to go down. If you're just getting started with accessibility, they have a checklist of all the first things that you should be covering to get your app started in that realm, to start making those improvements. I know you guys do links in the show notes. I can definitely send you those things to those items to get people started. Another thing I find myself doing a lot is while we're talking about something in our chat at work in or just go off in the code pin and mock something out in HTML and then see how the screen reader reads our content back to me and then kind of tinker with it and do a little bit of self-discovery in how this all works together. There's a lot of options out there. I know just threw a lot at your listeners but I'd say, it all starts with being someone who cares about the topic and cares enough to start asking others to care as well. CHARLES: I think that's a fantastic answer and a great note to end on. But before we go, obviously we will include those things in the show notes but also the other thing that we're going to include is a link that you actually, I understand, have a series of blog posts related to all of the things that you've been talking about, which we'll also include. KRIS: Awesome. Thanks. CHARLES: Everybody, go read it. Thank you so much Kris for coming and talking with us about accessibility. I think you're right. It is a topic that's gaining a lot more traction and a lot more mind share in the mainstream that can only be a good thing.
Kubernetes Joe Beda @jbeda | Heptio | eightypercent.net Show Notes: 00:51 - What is Kubernetes? Why does it exist? 07:32 - Kubernetes Cluster; Cluster Autoscaling 11:43 - Application Abstraction 14:44 - Services That Implement Kubernetes 16:08 - Starting Heptio 17:58 - Kubernetes vs Services Like Cloud Foundry and OpenShift 22:39 - Getting Started with Kubernetes 27:37 - Working on the Original Internet Explorer Team Resources: Google Compute Engine Google Container Engine Minikube Kubernetes: Up and Running: Dive into the Future of Infrastructure by Kelsey Hightower, Brendan Burns, and Joe Beda Joe Beda: Kubecon Berlin Keynote: Scaling Kubernetes: How do we grow the Kubernetes user base by 10x? Wordpress with Helm Sock Shop: A Microservices Demo Application Kelsey Hightower Keynote: Kubernetes Federation Joe Beda: Kubernetes 101 AWS Quick Start for Kubernetes by Heptio Open Source Bridge: Enter the coupon code PODCAST to get $50 off a ticket! The conference will be held June 20-23, 2017 at The Eliot Center in downtown Portland, Oregon. Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 70. With me is Elrick Ryan. ELRICK: Hey, what's going on? CHARLES: We're going to get started with our guest here who many of you may have heard of before. You probably heard of the technology that he created or was a key part of creating, a self-described medium deal. [Laughter] JOE: Thanks for having me on. I really appreciate it. CHARLES: Joe, here at The Frontside most of what we do is UI-related, completely frontend but obviously, the frontend is built on backend technology and we need to be running things that serve our clients. Kubernetes is something that I think I started hearing about, I don't know maybe a year ago. All of a sudden, it just started popping up in my Twitter feed and I was like, "Hmm, that's a weird word," and then people started talking more and more about it and move from something that was behind me into something that was to the side and now it's edging into our peripheral vision more and more as I think more and more people adopt it, to build things on top of it. I'm really excited to have you here on the show to just talk about it. I guess we should start by saying what is the reason for its existence? What are the unique set of problems that you were encountering or noticed that everybody was encountering that caused you to want to create this? JOE: That's a really good set up, I think just for way of context, I spent about 10 years at Google. I learned how to do software on the server at Google. Before that, I was at Microsoft working on Internet Explorer and Windows Presentation Foundation, which maybe some of your listeners had to actually go ahead and use that. I learned how to write software for the server at Google so my experience in terms of what it takes to build and deploy software was really warped by that. It really doesn't much what pretty much anybody else in the industry does or at least did. As my career progressed, I ended up starting this project called Google Compute Engine which is Google's virtual machine as a service, analogous to say, EC2. Then as that became more and more of a priority for the company. There was this idea that we wanted internal Google developers to have a shared experience with external users. Internally, Google didn't do anything with virtual machines hardly. Everything was with containers and Google had built up some really sophisticated systems to be able to manage containers across very large clusters of computers. For Google developers, the interface to the world of production and how you actually launched off and monitor and maintain it was through this toolset, Borg and all these fellow travelers that come along with it inside of Google. Nobody really actually managed machines using traditional configuration management tools like Puppet or Chef or anything like that. It's a completely different experience. We built a compute engine, GCE and then I had a new boss because of executive shuffle and he spun up a VM and he'd been at Google for a while. His reaction to the thing was like, "Now, what?" I was like I'm sitting there at the root prompt go and like, "I don't know what to do now." It turns out that inside of Google that was actually a common thing. It just felt incredibly primitive to actually have a raw VM that you could have SSH into because there's so much to be done above that to get to something that you're comfortable with building a production grade service on top of. The choice as Google got more and more serious about cloud was to either have everybody inside of Google start using raw VMs and live the life that everybody outside of Google's living or try and bring the experience around Borg and this idea of very dynamic, container-centric, scheduled-cluster thinking bring that outside of Google. Borg was entangled enough with the rest of Google systems that sort of porting that directly and externalizing that directly wasn't super practical. Me and couple of other folks, Brendan Burns and Craig McLuckie pitched this crazy idea of starting a new open source project that borrowed from a lot of the ideas from Borg but really melded it with a lot of the needs for folks outside of Google because again, Google is a bit of a special case in so many ways. The core problem that we're solving here is how do you move the idea of deploying software from being something that's based on these physical concepts like virtual machines, where the amount of problems that you have to solve, to actually get that thing up and running is actually pretty great. How do we move that such that you have a higher, more logical set of abstractions that you're dealing with? Instead of worrying about what kernel you're running on, instead of worrying about individual nodes and what happens if a node goes down, you can instead just say, "Make sure this thing is running," and the system will just do its best to make sure that things are running and then you can also do interesting things like make sure 10 of these things are running, which is at Google scale that ends up being important. CHARLES: When you say like a thing, you're talking about like a database server or API server or --? JOE: Yeah, any process that you could want to be running. Exactly. The abstraction that you think about when you're deploying stuff into the cloud moves from a virtual machine to a process. When I say process, I mean like a process plus all the things that it needs so that ends up being a container or a Docker image or something along those lines. Now the way that Google does it internally slightly different than how it's done with Docker but you can squint at these things and you can see a lot of parallels there. When Docker first came out, it was really good. I think at Docker and containers people look for three things out of it. The first one is that they want a packaged artifact, something that I can create, run on my laptop, run in a data center and it's mostly the same thing running in both places and that's an incredibly useful thing, like on your Mac you have a .app and it's really a directory but the finder treats it as you can just drag it around and the thing runs. Containers are that for the server. They just have this thing that you can just say, run this thing on the server and you're pretty sure that it's going to run. That's a huge step forward and I think that's what most folks really see in the value with respect to Docker. Other things that folks look at with containerized technology is a level of efficiency of being able to pack a lot of stuff onto a little bit of hardware. That was the main driver for Google. Google has so many computers that if you improve utilization by 1%, that ends up being real money. Then the last thing is, I think a lot of folks look at this as a security boundary and I think there's some real nuance conversations to have around that. The goal is to take that logical infrastructure and make it such that, instead of talking about raw VMs, you're actually talking about containers and processes and how these things relate to each other. Yet, you still have the flexibility of a tool box that you get with an infrastructure level system versus if you look at something like Heroku or App Engine or these other platform as a service. Those things are relatively fixed function in terms of their architectures that you can build. I think the container cluster stuff that you see with things like Kubernetes is a nice middle ground between raw VMs and a very, very opinionated platform as a service type of thing. It ends up being a building block for building their more specialized experiences. There's a lot to digest there so I apologize. CHARLES: Yeah, there's a lot to digest there but we can jump right into digesting it. You were talking about the different abstractions where you have your hardware, your virtual machine and the containers that are running on top of that virtual machine and then you mentioned, I think I'm all the way up there but then you said Kubernetes cluster. What is the anatomy of a Kubernetes cluster and what does that entail? And what can you do with it? JOE: When folks talk about Kubernetes, I think there's two different audiences and it's important to talk about the experience from each audience. There's the audience from the point of view of what it takes to actually run a cluster -- this is a cluster operator audience -- then there's the audience in terms of what it takes to use a cluster. Assuming that somebody else is running a cluster for me, what does it look like for me to go ahead and use this thing? This is really different from a lot of different dev app tools which really makes these things together. We've tried to create a clean split here. I'm going to skip past what it means to launch and run a Kubernetes cluster because it turns out that over time, this is going to be something that you can just have somebody else do for you. It's like running your own MySQL database versus using RDS in Amazon. At some point, you're going to be like, "You know what, that's a pain in the butt. I want to make that somebody else's problem." When it comes to using the cluster, pretty much what it comes down to is that you can tell a cluster. There's an API to a cluster and that API is sort of a spiritual cousin to something like the EC2 API. You can talk to this API -- it's a RESTful API -- and you can say, "Make sure that you have 10 of these container images running," and then Kubernetes will make sure that ten of those things are running. If a node goes down, it'll start another one up and it will maintain that. That's the first piece of the puzzle. That creates a very dynamic environment where you can actually program these things coming and going, scaling up and down. The next piece of the puzzle that really, really starts to be necessary then is that if you have things moving around, you need a way to find them. There is built in ideas of defining what a service is and then doing service discovery. Service discovery is a fancy name for naming. It's like I have a name for something, I want to look that up to an IP address so that I can talk to it. Traditionally we use DNS. DNS is problematic in the super dynamic environments so a lot of folks, as they build backend systems within the data center, they really start moving past DNS to something that's a lot more dynamic and purpose-built for that. But you can think about it in your mind as a fancy super-fast DNS. CHARLES: The customer is itself something that's abstract so I can change it state and configure it and say, "I want 10 instances of Postgres running," or, "I want between five and 15 and it will handle all of that for you." How do you then make it smart so that you can react to load, for example like all of the sudden, this thing is handling more load so I need to say... What's the word I'm looking for, I need to handle -- JOE: Autoscale? CHARLES: Yeah, autoscale. Are there primitives for that? JOE: Exactly. Kubernetes itself was meant to be a tool box that you can build on top of. There are some common community-built primitives for doing it's called -- excuse the nomenclature here because there's a lot of it in Kubernetes and I can define it -- Horizontal Pod Autoscaling. It's this idea that you can have a set of pods and you want to tune the number of replicas to that pod based on load. That's something that's built in. But now maybe you're cluster, you don't have enough nodes in your cluster as you go up and down so there's this idea of cluster autoscaling where I want to add more capacity that I'm actually launching these things into. Fundamentally, Kubernetes is built on top of virtual machines so at the base, there's a bunch of virtual or physical machines hardware that's running and then it's the idea of how do I schedule stuff into that and then I can pack things into that cluster. There's this idea of scaling the cluster but then also scaling workloads running on top of the cluster. If you find that some of these algorithms or methods for how you want to scale things when you want to launch things, how you want to hook them up, if those things don't work for you, the Kubernetes system itself is programmable so you can build your own algorithms for how you want to launch and control things. It's really built from the get go to be an extensible system. CHARLES: One question that's keeps coming up is as I hear you describing these things is the Kubernetes cluster then, it's not application-oriented so you could have multiple applications running on a single cluster? JOE: Very much so. CHARLES: How do you then layer on your application abstraction on top of this cluster abstraction? JOE: An application is made up of a bunch of running bits, whether it'd be a database. I think as we move towards microservices, it's not just going to be one set of code. It can be a bunch of sets of codes that are working together or bunch of servers that are working together. There are these ideas are like I want to run 10 of these things, I want to run five of these things, I want to run three of these things and then I want them to be able to find each other and then I want to take this thing and I want to expose it out to the internet through a load balancer on Amazon, for example. Kubernetes can help to set up all those pieces. It turns out that Kubernetes doesn't have an idea of an application. There is no actually object inside a Kubernetes called application. There is this idea of running services and exposing services and if you bring a bunch of services together, that ends up being an application. But in a modern world, you actually have services that can play double duty across applications. One of the things that I think is exciting about Kubernetes is that it can grow with you as you move from a single application to something that really becomes a service mesh, as your application, your company grows. Imagine that you have some sort of app and then you have your customer service portal for your internal employees. You can have those both being frontend applications, both running on a Kubernetes cluster, talking to a common backend with a hidden API that you don't expose to customers but it's something that's exposed to both of those frontends and then that API may talk to a database. Then as you understand your problems, you can actually spawn off different microservices that can be managed separately by different teams. Kubernetes becomes a platform where you can actually start with something relatively simple and then grow with that and have it stretch from single application to multiple service microservice-base application to a larger cluster that can actually stretch across multiple teams and there's a bunch of facilities for folks not stepping on each other's toes as they do this stuff. Just to be clear, this is what Kubernetes is as it's based. I think one of the powerful things that you can do is that there's a whole host to folks that are building more platform as a service like abstractions on top of Kubernetes. I'm not going to say it's a trivial thing but it's a relatively straightforward thing to build a Heroku-like experience on top of Kubernetes. But the great thing is that if you find that that Heroku experience, if some of the opinions that were made as part of that don't work for you, you can actually drop down to a level that's more useful than going all the way down to raw VM because right now, if you're running on Heroku and something doesn't work for you, it's like, "Here's a raw VM. Good luck with that." There's a huge cliff as you actually want to start coloring outside the lines for, as I mix my metaphors here for these platform services. ELRICK: What services that are out there that you can use that would implement Kubernetes? JOE: That's a great question. There are a whole host there. One of the folks in the community has pulled together a spreadsheet of all the different ways to install and run Kubernetes and I think there were something like 60 entries on it. It's an open source system. It's credibly adaptable in terms of running in all sorts of different mechanisms for places and there are really active startups that are helping folks to run that stuff. In terms of the easiest turnkey things, I would probably start with Google Container Engine, which is honestly one click. It fits within a Free Tier. It can get you up and running so that you can actually play with Kubernetes super easy. There's this thing from the folks at CoreOS called minikube that lets you run it on your laptop as a development environment. That's a great way to kick the tires. If you're on Amazon, my company Heptio has a quick start that we did with some of the Amazon community folks. It's a cloud formation template that launches a Kubernetes stack that you can get up and running and really understand what's happening. I think as users, understand what value it brings at the user level then they'll figure out whether they want to invest in terms of figuring out what the best place to run and the best way to run it for them is. I think my advice to folks would be find some way to start getting familiar with it and then decide if you have to go deep in terms of how to be a cluster operator and how to run the thing. ELRICK: Yup. That was going to be my next question. You just brought up your company, Heptio. What was the reason for starting that startup? JOE: Heptio was founded by Craig McLuckie, one of the other Kubernetes founders and me. We started about six months or seven months ago now. The goal here is to bring Kubernetes to enterprises and how do we bridge the gap of bringing some of this technology forward company thinking to think about companies like Google and Twitter and Facebook. They have a certain way of thinking about building a deployment software. How do we bring those ideas into more mainstream enterprise? How do we bridge that gap and we're really using doing Kubernetes as the tool to do that? We're doing a bunch of things to make that happen. The first being that we're offering training, support and services so right now, if companies want to get started today, they can engage with us and we can help them understand what makes sense there. Over time, we want to make that be more self-service, easier to do so that you actually don't have to hire someone like us to get started and to be successful there. We want to invest in the community in terms of making Kubernetes easier to approach, easier to run and then more applicable to a more diverse set of audiences. This conversation that we're having here, I'm hoping that at some point, we won't have to have this because Kubernetes will be easy enough and self-describing enough that folks won't feel like they have to dig deep to get started. Then the last thing that we're going to be doing is offering commercial services and software that really helps teach Kubernetes into the fabric of how large companies work. I think there's a set of tools that you need as you move from being a startup or a small team to actually dealing within the structure of a large enterprise and that's really where we're going to be looking to create and sell product. ELRICK: Gotcha. CHARLES: How does Kubernetes then compare in contrast to other technologies that we hear when we talk about integrating with the enterprise and having enterprise clients managing their own infrastructure things like Cloud Foundry, for example. From someone who's kind of ignorant of both, how do you discriminate between the two? JOE: Cloud Foundry is a more of a traditional platform as a service. There's a lot to like there and there are some places where the Kubernetes community and the Cloud Foundry community are starting to cooperate. There is a common way for provisioning and creating external services so you can say, "I want MySQL database." We're trying to make that idea of, "Give me MySQL database. I don't care who and where it's running." We're trying to make those mechanisms common across Cloud Foundry and Kubernetes so there is some effort going in there. But Cloud Foundry is more of a traditional platform as a service. It's opinionated in terms of the right way to create, launch, roll out, hooks services together. Whereas, Kubernetes is more of a building block type of thing. Kubernetes is, at least raw Kubernetes in some ways a more of a lower levels building block technology than something like Cloud Foundry. The most applicable competitor in this world to Cloud Foundry, I would say would be OpenShift from Red Hat. Open Shift is a set of extensions built on top of it. Right now, it's a little bit of a modified version of Kubernetes but over time that teams working to make it be a set of pure extensions on top of Kubernetes that adds a platform as a service layer on top of the container cluster layer. The experience for Open Shift will be comparable to the experience for Cloud Foundry. There's other folks like Microsoft just bought the small company called Deis. They offer a thing called Workflow which gives you a little bit of the flavor of a platform as a service also. There's multiple flavors of platforms built on top of Kubernetes that would be more apples to apples comparable to something like Cloud Foundry. Now the interesting thing with thing Deis' Workflow or Open Shift or some of the other platforms built on top of Kubernetes is that, again if you find yourself where that platform doesn't work for you for some reason, you don't have to throw out everything. You can actually start picking and choosing what primitives you want to drop down to in the Kubernetes world without having to go down to raw VMs. Whereas, Cloud Foundry really doesn't have a widely supported, sort of more raw interface to run in containers and services. It's kind of subtle. CHARLES: Yeah, it's kind of subtle. This is an analogy that just popped into my head while I was listening to you and I don't know if this is way off base. But when you were describing having... What was the word you used? You said a container clast --? It was a container clustered... JOE: Container orchestrator, container cluster. These are all -- CHARLES: Right and then kind of hearkening back to the beginning of our conversation where you were talking about being able to specify, "I want 10 of these processes," or an elastic amount of these processes that reminded me of Erlang VM and how kind of baked into that thing is the concept of these lightweight processes and be able to manage communication between these lightweight processes and also supervise these processes and have layers of supervisors supervising other supervisors to be able to declare a configuration for a set of processes to always be running. Then also propagate failure of those processes and escalate and stuff like that. Would you say that there is an analogy there? I know there are completely separate beast but is there a co-evolution there? JOE: I've never used Erlang in Anger so it's hard for me to speak super knowledgeably about it. For what I understand, I think there is a lot in common there. I think Erlang was originally built by Nokia for telecoms switches, I believe which you have these strong availability guarantees so any time when you're aiming for high availability, you need to decouple things with outside control loops and ways to actually coordinate across pieces of hardware and software so that when things fail, you can isolate that and have a blast radius for a failure and then have higher level mechanisms that can help recover. That's very much what happens with something like Kubernetes and container orchestrator. I think there's a ton of parallels there. CHARLES: I'm just trying to grasp at analogies of things that might be -- ELRICK: I think they call that the OTP, Open Telecom Platform or something like that in Erlang. CHARLES: Yeah, but it just got a lot of these things -- ELRICK: Very similar. CHARLES: Yeah, it seems very similar. ELRICK: Interestingly enough, for someone that's starting from the bottom, an initiated person to Kubernetes containers, Docker images, Docker, where would they start to ramp up themselves? I know you mentioned that you are writing a book --? JOE: Yes. ELRICK: -- 'Kubernetes: Up and Running'. Would that be a good place to start when it comes out or is there like another place they should start before they get there. What is your thoughts on that? JOE: Definitely, check out the book. This is a book that I'm writing with Kelsey Hightower who's one of the developer evangelists for Google. He is the most dynamic speaker I've ever seen so if you ever have a chance to see him live, it's pretty great. But Kelsey started this and he's a busy guy so he brought in Brendan Burns, one of the other Kubernetes co-founders and me to help finish that book off and that should be coming out soon. It's Kubernetes: Up and Running. Definitely check that out. There's a bunch of good tutorials out there also that start introducing you to a lot of the concepts in Kubernetes. I'm not going to go through all of those concepts right now. There's probably like half a dozen different concepts and terminology, things that you have to learn to really get going with it and I think that's a problem right now. There's a lot to import before you can get started. I gave a talk at the Kubernetes Conference in Berlin, a month or two ago and it was essentially like, yeah we got our work cut out for us to actually make the stuff applicable to wider audience. But if you want to see the power, I think one of the things that you can do is there's the system built on top of Kubernetes called Helm, H-E-L-M, like a ship's helm because we love our nautical analogies here. Helm is a package manager for Kubernetes and just like you can login to say, in Ubuntu machine and do apps get install MySQL and you have a database up and running. With Helm you can say, create and install 'WordPress install' on my Kubernetes cluster and it'll just make that happen. It takes this idea of package management of describing applications up to the next level. When you're doing regular sysadmin stuff, you can actually go through and do the system to [Inaudible] files or to [Inaudible] files and copy stuff out and use Puppet and Chef to orchestrate all of that stuff. Or you can take the stuff that sort of package maintainers for the operating system have done and actually just go ahead and say, "Get that installed." We want to be able to offer a similar experience at the cluster level. I think that's a great way to start seeing the power. After you understand all these concepts here is how easy you can make it to bring up and run these distributed systems that are real applications. The Weaveworks folks, there are company that do container networking and introspection stuff based out of London. They have this example application called Sock Shop. It's like the pet shop example but distributed and built to show off how you can build an application on top of Kubernetes that pulls a lot of moving pieces together. Then there's some other applications out there like that that give you a little bit of an idea of what things look like as you start using this stuff to its fullest extent. I would say start with something that feels concrete where you can start poking around and seeing how things work before you commit. I know some people are sort of depth first learners and some are breadth first learners. If you're depth first, go and read the book, go to Kubernetes documentation site. If you're breadth first, just start with an application and go from there. ELRICK: Okay. CHARLES: I think I definitely fall into that breadth first. I want to build something with it first before trying to manage my own cluster. ELRICK: Yeah. True. I think I watched your talk and I did watch one of Kelsey's talks: container management. There was stuff about replicators and schedulers and I was like, "The ocean just getting deeper and deeper," as I listened to his talk. JOE: Actually, I think this is one of the cultural gaps to bridge between frontend and backend thinking. I think a lot of backend folks end up being these depths first types of folks, where when they want to use a technology, they want to read all the source code before they first apply it. I'm sure everybody has met those type of developers. Then I think there's folks that are breadth first where they really just want to understand enough to be effective, they want to get something up and running, they want to like if they hit a problem, then they'll go ahead and fix that problem but other than that, they're very goal-oriented towards, I want to get this thing running. Kubernetes right now is kind of built by systems engineers for systems engineers and it shows so we have our work cut out for us, I think to bridge that gap. It's going to be an ongoing thing. ELRICK: Yeah, I'm like a depth first but I have to keep myself in check because I have to get work done as a developer. [Laughter] JOE: That sounds about right, yeah. Yeah, so you're held accountable for writing code. CHARLES: Yeah. That's where real learning happens when you're depth first but you've got deadlines. ELRICK: Yes. CHARLES: I think that's a very effective combination. Before we go, I wanted to switch topic away from Kubernetes for just a little bit because you mentioned something when we were emailing that, I guess in a different lifetime you were actually on the original IE team or at the very beginning of the Internet Explorer team at Microsoft? JOE: Yes, that's where I started my career. Back in '97, I've done a couple of internships at Microsoft and then went to join full time, moved up here to Seattle and I had a choice between joining the NT kernel team or the Internet Explorer team. This was after IE3 before IE4. I don't know if this whole internet thing is going to pan out but it looks like that gives you a lot of interesting stuff. You got to understand the internet, it wasn't an assumed thing back then, right? ELRICK: Yeah, that's true. JOE: I don't know, this internet thing. CHARLES: I know. I was there and I know that like old school IE sometimes gets a bad rap. It does get a bad rap for being a little bit of an albatross but if you were there for the early days of IE, it really was the thing that blew it wide open like people do not give credit. It was extraordinarily ahead of its time. That was [Inaudible] team that coin DHTML back to when it was called DHTML. I remember, actually using it for the first time, I think about '97 is about what I was writing raw HTML for everything. CSS wasn't even a thing hardly. When I realized, all these static things when we render them, they're etched in stone. The idea that every one of these properties which I already knew is now dynamic and completely reflected, just moment to moment. It was just eye-opening. It was mind blowing and it was kind of the beginning of the next 20 years. I want to just talk a little bit about that, about where those ideas came from and what was the impetus for that? JOE: Oh, man. There's so much history here. First of all, thank you for calling out. I think we did a lot of really interesting groundbreaking work then. I think the sin was not in IE6 as it was but in [inaudible]. I think the fact that -- CHARLES: IE6 was actually an amazing browser. Absolutely an amazing browser. JOE: And then the world moved past it, right? It didn't catch up. That was the problem. For its time when it was released, I was proud of that release. But four years on, things get a little bit long in the tooth. I think IE3 was based on rendering engine that was very static, very similar to Netscape at the time. The thing to keep in mind is that Netscape at that time, it would download a webpage, parse it and display it. There was no idea of a DOM at Netscape at that point so it would throw away a lot of the information and actually only store stuff that was very specific to the display context. Literally, when you resize the window for Netscape back then, it would actually reparse the original HTML to regenerate things. It wasn't even able to actually resize the window without going through and reparsing. What we did with IE4 -- and I joined sort of close to the tail on IE4 so I can't claim too much credit here -- is bringing some of the ideas from something like Visual Basic and merge those into the idea of the browser where you actually have this programming model which became the DOM of where your controls are, how they fit together, being able to live modify these things. This was all part and parcel of how people built Windows applications. It turns out that IE4 was the combination of the old IE3 rendering engine, sort of stealing stuff from there but then this project that was built as a bunch of Active X controls for Office called [inaudible]. As you smash that stuff together and turn it into a browser rendering engine, that browser rendering engine ended up being called Trident. That's the thing that got a nautical theme. I don't think it's connected and that's the thing that that I joined and started working on at the time. This whole idea that you have actually have this DOM, that you can modify a programmable representation of DHTML and have it be live updated on screen, that was only with IE4. I don't think anybody had done it at that point. The competing scheme from Netscape was this thing called layers where it was essentially multiple HTML documents where you could replace one of the HTML documents and they would be rendered on top of each other. It was awful and it lost to the mist of time. CHARLES: I remember marketing material about layers and hearing how layers was just going to be this wonderful thing but I don't ever remember actually, did they ever even ship it? JOE: I don't know if they did or not. The thing that you got to understand is that anybody who spent any significant amount of time at Microsoft, you just really internalize the idea of a platform like no place else. Microsoft lives and breathes platforms. I think sometimes it does them a disservice. I've been out of Microsoft for like 13 years now so maybe some of my knowledge is a little outdated here but I still have friends over there. But Microsoft is like the poor schmuck that goes to Vegas and pulls the slot machine and wins the jackpot on the first pull. I'm not saying that there wasn't a lot of hard work that went behind Windows but like they hit the goldmine with that from a platform point of view and then they essentially did it again with Office. You have these two incredibly powerful platforms that ended up being an enormous growth engine for the company over time so that fundamentally changed the world view of Microsoft where they really viewed everything as a platform. I think there were some forward thinking people at Netscape and other companies but I think, Microsoft early on really understood what it meant to be a platform and we saw back then what the web could be. One of the original IE team members, I'm going to give a shout out to him, Chris Wilson who's now on the Chrome team, I think. I don't know where he is these days. Chris was on the original IE team. He's still heavily involved in web standards. None of this stuff is a surprise to us. I look at some of the original so after we finished IE6, a lot of the IE team rolled off to doing Avalon which became Windows Presentation Foundation, which was really looking to sort of reinvent Windows UI, importing a bunch of the ideas from web and modern programming there. That's where we came up with XAML and eventually begat Silverlight for good or ill. But some of our original demos for Avalon, if you go back in time and look at that, that was probably... I don't know, 2000 or something like that. They're exactly the type of stuff that people are building with the web platform today. Back then, they'll flex with the thing. We're reinventing this stuff over and over again. I like where it's going. I think we're in a good spot right now but we see things like the Shadow DOM come up and I look at that and I'm like, "We had HTC controls which did a lot of Shadow DOM stuff like stuff in IE early on." These things get reinvented and refined over time and I think it's great but it's fascinating to be in the industry long enough that you can see these patterns repeat. CHARLES: It is actually interesting. I remember doing UI in C++ and in Java. We did a lot of Java and it was a long time. I felt like I was wandering in the wilderness of the web where I was like, "Oh, man. I just wish we had these capabilities of things that we could do in swing, 10 or 15 years ago," but the happy ending is that I really actually do feel we are in a place now, finally where you have options for it really is truly competitive as a developer experience to the way it was, these many years ago and it's also a testament just how compelling the deployment model of the web is, that people were willing to forgo all of that so they could distribute their applications really easily. JOE: Never underestimate the power of view source. CHARLES: Yeah. [Laughter] ELRICK: I think that's why this sort of conversations are very powerful, like going back in time and looking at the development up until now because like they say that people that don't know their history, they're doomed to repeat it. I think this is a beautiful conversation. JOE: Yeah. Because I've done that developer focused frontend type of stuff. I've done the backend stuff. One of the things that I noticed is that you see patterns repeat over and over again. Let's be honest, it probably more like a week, I was going to say a weekend and learn the React the other day and the way that it encapsulate state up and down, model view, it's like these things are like there's different twists on them that you see in different places but you see the same patterns repeat again and again. I look at the way that we do scheduling in Kubernetes. Scheduling is this idea that you have a bunch of workloads that have a certain amount of CPU and RAM that they require like you want to play this Tetris game of being able to fit these things in, you look at scheduling like that and there are echoes for how layout happens in a browser. There is a deeper game coming on here and as you go through your career and if you're like me and you always are interested in trying new things, you never leave it all behind. You always see things that influence your thinking moving forward. CHARLES: Absolutely. I kind of did the opposite. I started out on the backend and then moved over into the frontend but there's never been any concept that I was familiar with working on server side code that did not come to my aid at some point working on the frontend. I can appreciate that fully. ELRICK: Yup. I can agree with the same thing. I jump all around the board, learning things that I have no use currently but somehow, they come back to help me. CHARLES: That will come back to help you. You thread them together at some point. ELRICK: Yup. CHARLES: As they said in one of my favorite video games in high school, Mortal Kombat there is no knowledge that is not power. JOE: I was all Street Fighter. CHARLES: Really? [Laughter] JOE: I cut class in high school and went to play Street Fighter at the mall. CHARLES: There is no knowledge that isn't power except for... I'm not sure that the knowledge of all these little mashy key buttons combinations, really, I don't think there's much power in that. JOE: Well, the Konami code still shows up all the time, right? [Laughter] CHARLES: I'm surprised how that's been passed down from generation to generation. JOE: You still see it show up in places that you wouldn't expect. One of the sad things that early on in IE, we had all these Internet Explorer Easter eggs where if you type this right combination into the address bar, do this thing and you clicked and turn around three times and face west, you actually got this cool DHTML thing and those things are largely disappearing. People don't make Easter eggs like they used to. I think there's probably legal reasons for making sure that every feature is as spec. But I kind of missed those old Easter eggs that we used to find. CHARLES: Yeah, me too. I guess everybody save their Easter eggs for April 1st but -- JOE: For the release notes, [inaudible]. CHARLES: All right. Well, thank you so much for coming by JOE. I know I'm personally excited. I'm going to go find one of those Kubernetes as a services that you mentioned and try and do a little breadth first learning but whether you're depth first or breadth first, I say go to it and thank you so much for coming on the show. JOE: Well, thank you so much for having me on. It's been great. CHARLES: Before we go, there is actually one other special item that I wanted to mention. This is the Open Source Bridge which is a conference being held in Portland, Oregon on the 20th to 23rd of June this year. The tracks are activism, culture hacks, practice and theory and podcast listeners may be offered a discount code for $50 off of the ticket by entering in the code 'podcast' on the Event Brite page, which we will link to in the show notes. Thank you, Elrick. Thank you, Joe. Thank you everybody and we will see you next week.
Glenn Davis is the creator of Cool Site of the Day; cofounder of Project Cool; and cofounder, Executive Committee member, and essayist for The Web Standards Project, which he also hosted. Glenn was a leading force behind Liquid Design, an approach that predates Responsive Web Design by about 20 years. He taught everyone how to do “DHTML” via his Project Cool tutorials. In the Silicon Valley from 1994 through the early 2000s, Glenn was a huge creative force. In a lively hour, Glenn and host Jeffrey Zeldman discuss life before the animated GIF; “perceived bandwidth;” building their first websites; getting from Gopher to the web; SLIP and PPP connections; discovering UNIX; the story behind Cool Site of the Day; the battle for standards in our browsers; the web then versus the web now; and much, much more.
Glenn Davis is the creator of Cool Site of the Day; cofounder of Project Cool; and cofounder, Executive Committee member, and essayist for The Web Standards Project, which he also hosted. Glenn was a leading force behind Liquid Design, an approach that predates Responsive Web Design by about 20 years. He taught everyone how to do “DHTML” via his Project Cool tutorials. In the Silicon Valley from 1994 through the early 2000s, Glenn was a huge creative force. In a lively hour, Glenn and host Jeffrey Zeldman discuss life before the animated GIF; “perceived bandwidth;” building their first websites; getting from Gopher to the web; SLIP and PPP connections; discovering UNIX; the story behind Cool Site of the Day; the battle for standards in our browsers; the web then versus the web now; and much, much more. Brought to you by: Braintree (To learn more visit BraintreePayments.com/BigWebShow)
Episode 15 deep dives into the programming experiences of Adam Solove (@asolove), Head of Engineering at Pagemodo. Adam has spent the last ten years building web interfaces various technologies such as CGI, Flash, DHTML, RJS, jQuery, and many MVC JavaScript frameworks. Adam has found over his career that working with a more functional style of programming is much more rewarding in many ways. Functional programming and FRP (Functional Reactive Programming) provides improvements in performance and purposely avoids changing-state and mutable data. This can be an extremely effective technique in web application development because of the stateful nature of DOM (Document Object Model) implementations in the browser. Adam evangelizes and works with several languages and tools to provide incredible functional style applications including, but not limited to, Elm, ClojureScript, OM, & React.js. Facebook's React.js, met with mixed reviews when it was first released in 2013. Since then it has been stirring up support in droves within the JavaScript development community do to it's high UI performance output in browsers. It's Virtual DOM and ways of solving data & DOM performance problems have been highly criticized but hard to ignore. React has an effective unorthodox way of thinking about UI. Elm, a functional reactive language for interactive applications, combines core features of functional languages like immutability & type inference with FRP to Create highly interactive applications without callbacks or shared state. Elm is similar in syntax to Haskell and it compiles to HTML, CSS, and JavaScript that uses a Virtual DOM model similar in concepts to that of react.js. According to Elm's internal benchmarks, using it's compiled JavaScript code is actually faster than any JavaScript framework tested by a extreme margin. ClojureScript, is a new compiler for Clojure that targets JavaScript. It is designed to emit JavaScript code which is compatible with the advanced compilation mode of the Google Closure optimizing compiler. David Nolen, has taken ClojureScript and created an interface for react.js called OM. Om allows for simple represention of Web Application User Interfaces as an EDN. ClojureScript data is immutable data, which means that Om can always rapidly re-render the UI from the root. According to the project description, UIs created with Om are inherently able to create & manage historical snapshots with no implementation complexity and little overhead. Resources Why use Functional Style? - http://stackoverflow.com/questions/36504/why-functional-languages Lambda: the ultimate syntax-semantics interface - http://okmij.org/ftp/gengo/NASSLLI10/ Haskell -http://www.haskell.org/haskellwiki/Haskell Adam Solove - http://adamsolove.com/ Adam's talk on ClojureScript/OM - http://adamsolove.com/js/clojure/2014/05/08/react-js-and-om.html Elm Elm's Virtual DOM - http://elm-lang.org/blog/Blazing-Fast-Html.elm Elm's Time Travelling Debugger - http://debug.elm-lang.org/ ClojureScript & OM ClojureScript Intro 2011 - http://clojure.com/blog/2011/07/22/introducing-clojurescript.html A feature comparison to JavaScript - http://himera.herokuapp.com/synonym.html David Nolen - https://twitter.com/swannodette/ David Nolen's Benchmarks - http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ Todo MVC - https://github.com/swannodette/todomvc/tree/gh-pages/labs/architecture-examples/om/src/todomvc React.js Reactjs - http://facebook.github.io/react/ Secrets of The Virtual DOM - http://fluentconf.com/fluent2014/public/schedule/detail/32395 React Demystified - React Diff Algorithm - http://calendar.perfplanet.com/2013/diff/
This episode was recorded 17 May 2013 live and in person at Omni's beautiful offices overlooking Lake Union in Seattle. You can download the m4a file or subscribe in iTunes. (Or subscribe to the podcast feed.) Mike Lee, Appsterdam founder, has worked at Alaska Airlines, Delicious Monster (with Wil Shipley), Apple, and is now Chief Lemur at New Lemurs. This episode is sponsored by Hover. Hover makes domain name management easy. And it's a snap to transfer domains from other registrars using their valet service. Get 10% off your first purchase with the promotional code BMF. (BMF -- Be My Friend — is Mike Lee's Twitter handle.) You notice how people with a lot of domains are always talking about Hover? It's because of their excellent service. Take a look. This episode is also sponsored by Microsoft Azure Mobile Services. Mobile Services is a great way to provide backend services — syncing and other things — for your iPhone, iPad, and Mac apps. It's high level — you can get more done with less work. It's also deep: write JavaScript in your favorite text editor. Test with mocha. Deploy with git. Things we mention, in order of appearance (mostly): Kurt Cobain Grunge Honolulu Hawaii University of Puget Sound Tacoma Puget Sound Alaska Airlines SeaTac Lead ramp agent Skilled labor 1993 Choose Your Own Adventure DHTML Flash Web Standards Project XML Java C# DotNet Macintosh PC Microsoft Windows Windows 95 Mac OS X Terrorist watch list WWDC JavaOne Objective-C Xcode 2005 2001 Renoir Hotel WWDC Student Scholarship Wil Shipley Wil Shipley's Speech on the Indie Dream Devry FedEx Core Data Bill Bumgarner Federal Way I-5 Delicious Library Apple Design Award Campus Bash Denny's Omni Group Rumpus Room Apple Store Barnes & Noble Lucas Newman Mike Matas Knoxville Samurai Yoko Ono Seattle Xcoders Gus Mueller Heisenberg Uncertainty Principle Dave Winer Superman IL 7 John Geleynse Lemur Chemistry Cabel Sasser “Hi, I Make Macintosh Software” T-shirt altWWDC Debug podcast Tapulous Tap Tap Revenge iFart DTS IL 3 Caffè Macs Rands Matt Drance Michael Jurewitz
Brad Westfall is the Senior PHP Web Developer at Vianet Management, Inc in Scottsdale, AZ. Brad has over 13 years experience in Web Design and Development. Brad's past work includes being the founder and President of AZPixels.com, LLC. Brad's professional experience includes building and maintaining high visibility LAMP projects, conducting search engine optimization and business branding. Brad has worked with over 200 clients including: ASU, The Department of Education (Arizona), AlphaGraphics, and Vianet Management. Owner of Roommates.com and PuppyFind.com. Brad's technical knowledge includes PHP, MySQL, browser compatible HTML and CSS, User Interface, User Experience and JavaScript. Brad received his Bachelors of Science in Computer Information Systems Degree at ASU's W.P. Carey School of Business. In his free time, Brad participates and mentors in several Web Developer and User Experience Groups in the Phoenix area. Brad has a passion for learning and strives to bridge the gap between engineering and designer roles. Presentation: Was recorded at the University of Advancing Technology Tech Forum Spring 2012
Web-Anwendungen - Einfuehrung in das YUI JavaScript/AJAX Framework von Yahoo
Beschreibung Diesmal geht es nicht direkt ums Programmieren sondern um die Vorbereitung - Wireframes bzw. Mockups! Im Podcast wird eine Software namens Wireframe Sketcher (http://wireframesketcher.com) vorgestellt. Bei dem Tool handelt es sich um ein Eclipse-Plugin, welches bei der Konzeption von Website-Prototypen hilft. © by podcast@michael-reiher.de
Web-Anwendungen - Einfuehrung in das YUI JavaScript/AJAX Framework von Yahoo
Beschreibung Heute mal etwas in eigener Sache: Ich habe das Glück bei der Podcast.de Umfrage 2009 teilnehmen zu dürfen. Bitte unterstützt mich durch eure Teilnahme an der Umfrage noch gleich heute! Vielen Dank! © by podcast@michael-reiher.de
Web-Anwendungen - Einfuehrung in das YUI JavaScript/AJAX Framework von Yahoo
Beschreibung Die Buttons "Weiter" und "Zurück" im Webbrowser sind für Besucher von Webseiten zur schnellen Navigation sehr hilfreich. Leider verlieren die Buttons bei clientseitigen Veränderungen der Webseite ihre Funktionalität. Auch das Anlegen von Lesezeichen wird häufig zum Problem. Mit Hilfe des YUI History Manager ist es möglich, sowohl die Navigations-Buttons als auch die Bookmark-Funktionalität in Webanwendungen zu nutzen. © by podcast@michael-reiher.de
Web-Anwendungen - Einfuehrung in das YUI JavaScript/AJAX Framework von Yahoo
Beschreibung Der Podcast zeigt unterschiedliche Möglichkeiten für ein 3-Spaltiges CSS-Layout. Aufgrund der Gestaltung mittels floating-Divs ist die gleiche Höhe der Spalten im Gegensatz zu tabellenbasierten Layouts jedoch nicht trivial. An konkreten Beispielen wird zunächst das Problem aufgezeigt und unterschiedliche Lösungen beschrieben (Faux Columns, YUI Grids, pure CSS). © by podcast@michael-reiher.de
Beschreibung Mittels des Jaxer-Servers lassen sich JavaScript-Libs auch serverseitig nutzen. Ajax, HTML, JavaScript und Dom Kenntnisse lassen sich 1-zu-1 auf die serverseitige Programmierung übertragen. Auch Datei-, Datenbank- und Netzwerkzugriffe sind mit Jaxer kein Problem. Ob JavaScript langfristig eine Konkurrenz zu PHP, C# und RoR wird, bleibt abzuwarten. Links JavaScript- und PHP-Scripte: www.michael-reiher.de/podcast Jaxer-Server: http://www.aptana.com/jaxer by podcast@michael-reiher.de
Die Vorlesung gibt an zwei Beispielen einen Einblick in Sriptsprachen für die Erstellung dynamischer Webseiten.
Die Vorlesung gibt an zwei Beispielen einen Einblick in Sriptsprachen für die Erstellung dynamischer Webseiten.
Web-Anwendungen - Einfuehrung in das YUI JavaScript/AJAX Framework von Yahoo
Beschreibung Im Podcast werden die YUI-Container-Elemente (Overlay und Panel) vorgestellt. Overlays lassen sich absolut auf einer HTML-Seite positionieren ohne die eigentliche HTML-Seite zu beeinflussen. Im Gegensatz zum Panel-Element sind bei Overlays allerdings keine CSS-Angaben hinterlegt. Panel lassen sich mit einfachen Fenstern im Betriebssystem vergleichen - diese Panel lassen sich vor der eigentlichen Webseite wie gewohnt verschieben, vergrößern/verkleinern und schließen. Links JavaScript- und PHP-Scripte: www.michael-reiher.de/podcast by podcast@michael-reiher.de
Web-Anwendungen - Einfuehrung in das YUI JavaScript/AJAX Framework von Yahoo
XSS (X-Site-Scripting) - Nachdem eine HTML-Seite von einem Server gelden wurde werden weitere Inhalte von einem anderen Server dynamisch nachgeladen. JavaScript- und PHP-Scripte: www.michael-reiher.de/podcast by podcast@michael-reiher.de
Marquand.net Solitaire versions of Clans, Coloretto and Ingenious All programmed in DHTML and Javascript pr-game.com PBW Puerto Rico One of the oldest and still great implementations of PBW Puerto Rico
Web-Anwendungen - Einfuehrung in das YUI JavaScript/AJAX Framework von Yahoo
Beschreibung: Dynamisches nachladen von Inhalten von einem Server in eine HTML-Seite.JavaScript- und PHP-Scripte: www.michael-reiher.de/podcast
Web-Anwendungen - Einfuehrung in das YUI JavaScript/AJAX Framework von Yahoo
Beschreibung: Dynamisches nachladen von Inhalten von einem Server in eine HTML-Seite.JavaScript- und PHP-Scripte: www.michael-reiher.de/podcast
© 2020-2025 Ivy Podcast Discovery LLC
