Podcasts about es5

Play Episode Listen Later Apr 12, 2020 18:23

Lo que sale si mezclas Pactar con el diablo y Cubo en la cabeza de Asimov. Ps: VED "EL HOYO", INSENSATOS!! De Galder Gaztelu-Urrutia y Guión de David Desola y Pedro Rivero [semi-spoilers] Estoy subiendo morralla que se había quedado por mi ordenador. Volveré a subir alguna cosa mejor. Este cuento sin embargo merece un lugar porque no es muy conocido, siendo de quien es, y toca temas que no se suelen tocar tanto el ciencia ficción. El trope de "la habitación cerrada", algo presente en muchos lugares culturales desde la proliferación de Scape Rooms hasta los enigmas de responder "Sí" o "No" (había uno de un tipo en una habitación cerrada sin ventanas ni muebles que se había ahorcado y tenías que averiguar cómo). O sin irnos lejos pero muy forzado, esa movida de las piedras de la India que aparecen dentro de habitaciones sin haber ventanas que comentan en La Mosca y dije que me interesaba. Lo traigo para recomendaros que veáis "El Hoyo". Está genial. Siempre desconfío pero me encantó, no me parece que se posicione políticamente y creo que la construcción fantástica no es nada gratuita, está muy justificada, el guión avanza, las ideas van fluyendo y los debates se van planteándola. No la veáis con las expectativas altísimas porque entonces ya sabéis, pero una peli que se agradece mucho mucho mucho!!!!! Nota: El título de este relato ha ido variando, se público con el nombre (en inglés) La Habitación de bronce cerrada, en 1956 en la revista Magazine of Fantasy and Science Fiction pero en castellano se ha publicado también como "La treta tridimensional" Añado aquí link a una página con pactos con el diablo "reales" auténticos https://www.strambotic.com/sofia/estos-son-los-documentos-reales-de-pactos-con-el-diablo/ La música vuelve a ser nuestro favorito ES5 también conocido como el hombre-máquina Pedro López-Hernández el macgiver del newmedia art, lo generativo, lo procedural y lo estocásticopsicodélico por igual!!! Bravo! jefe! Y al final el main theme de El irishman que es la hostia, me encanta como va bajando la melodía... en la escala pero también en el timbre de los instrumentos... grutal.

fantasy magazine siempre bravo science fiction hern volver asimov cubo el hoyo la habitaci la mosca pedro l pactar nota el es5

[Maupassant] Carta de un loco (1885)

Play Episode Listen Later Apr 12, 2020 23:59

Una reflexión romántica sobre los límites de la percepción “Un órgano de más o de menos en nuestra máquina, nos hubiera dado una inteligencia distinta” – Montesquieau Subo este cuento porque ha de estar en esta colección de antecedentes y porque ya lo tenía grabado de hace un año (mísero de mí) pero os urjo aque vayáis a escucharlo en Noviembre Nocturno y después le déis a “El Horla”. [semi-spoilers] Este cuento es un referente antecedente primigenio que había que traer aquí. Lo escribió el autor de “El Horla” un par de años, y yo diría que es como una precuela, o que al menos sirve de base. Pero es que sirve de base para un montón de literatura fantástica que ha venido después. Es un antecedente máximo. Escrito además por un escritor romántico, en una época de invenciones y descubrimientos… Bueno, yo os recomendaría que vayáis a escuchar “El Horla”. No sé si NN y compañía lo han subido ya pero en este caso recomiendo con amor escucharlo con Juan Jose Plans y su equipo de RNE. El programa “Historias”. Buscadlo. Si no conocéis el programa, se os acaba de abrir un mundo de radiodrama maravilloso. Adoro a Juan Jose Plans y los recuerdos de mi escucharlo de pequeño o hace mucho menos tiempo en coche o de viaje están llenos de calor en mi corazón. “Un día me di cuenta de que todo es falso”. Empieza a reflexionar en la frase y empieza a penetrar en él una cierta “claridad” que al poco deriva en oscuridad. Es decir, al convertirse en escéptico, al reconocer lo limitado de los sentidos y la naturaleza constructiva de la percepción, empieza a debilitarse su sentimiento de realidad. Se abre la puerta al brote, a la locura. Cuantas son las historias en las que debido a una revelación el protagonista acaba perdiendo la cabeza. Se está mejor en la ignorancia? Esta vez más que un cuento se trata de un ensayo filosófico-patafísico. ¿Qué pasaría si tuviéramos otros órganos? Por ejemplo un sentido para las variaciones en los campos electromagnéticos. Las palomas ya lo llevan y algunas bacterias se orientan por las líneas Ley o líneas magnéticas. Y si en vez de hechos de CHONPS (Carbono, Hidrógeno, Oxígeno, Nitrógeno , Fósforo y Azufre) estuviéramos hechos de otros elementos, por ejemplo gases nobles invisibles e inodoros? Como dice el cuento, si tuviéramos órganos de más descubriríamos otras cosas, que desconocemos. Realmente conocemos? Estamos rodeados de desconocido. De ahí a la locura hay un paso: puedes asumir que por tanto todo es “inseguro, falso, posible, dudoso”. Me encanta porque el cuento está escrito en la épioca de lauge científico, del newtonianismo – y promulga un relativismo escéptico que es claramente la opción más prudente. Eran los tiempos del descubrimiento del funcionamiento de la electricidad y le magnetismo. El desarrollo del mesmerismo. Mesmer. Lo más magufo divertido que hay por que rezuma un aroma steampunk histórico. Este cuento es un avance intelectual-filosófico fundamental en materia ciencia-ficción, fantasía. Por supuesto que no aporta nada que no haya aportado el pensamiento científico, pero le da forma cultural. Desde el punto de vista del paradigma científico, que trata de describir, explicar y predecir, compone una hipótesis que sólo se puede plantear en el terreno literario. Y es una consecuencia directa del auge del empirismo. Si sólo vale lo “positivo”, es decir aquello que es mensurable, pesable, medible, cuantificable… Qué pasa con todo lo que no se puede medir? Acaso no existe? Claro, no podremos decir nada de ello desde la ciencia… Pero la ciencia misma crea elementos que expliquen esos huecos. Son los tiempos del ÉTER. Hoy tenemos la materia oscura… Este cuento sienta los mecanismos para introducir la fantasía en la prosa realista y autoriza el resto de idas de olla que vengan después. Este cuento tiene que estar asociado a “El Horla” y por favor, acudid a escucharlo, Cuentos que hablen sobre constructivismo y sobre la fantasía de la Percepción he subido alguno. Es que este cuento realmente abre un melón que lo ha impregnado todo posteriormente. De Dick, lo asociaré con La Hormiga Eléctrica, así ha de ser. Además de parte de un directo de Tubular Bells para la BBC de 1973 y un poquito de Riders on the Storm he tenido la suerte de poder usar para ambientar la música de ES5, Pedro López-Hernández, mi jubilado favorito que es precisamente experto en campos electromagnéticos y ondas hertzianas y más allá, y que tanto te programa un instrumento sinéstesico con un nuevo programa que acaba de aprender como transmuta datos fisiológicos en paisajes sonoros, graba en 560mil grados y cinco dimensiones, recoge sonidos fonendoscópicos, dibuja con osciloscopios, crea mallas renderizadas de vectores cuánticos o aprovecha la inteligencia artificial para sus propios menesteres. No estoy de coña! Está muy loco, pero en el buen sentido, no en el del cuento… Podéis ver sus creaciones y buscarle en las redes. Y por supuesto su animal totémico son las salamandras/lagartos y lagartijas! (el escinco es un reptil muy majo). Paz! Ilustración: Rouen

[Asimov] El artilugio tridimensional (1956)

Play Episode Listen Later Apr 12, 2020 18:23

Lo que sale si mezclas Pactar con el diablo y Cubo en la cabeza de Asimov. Ps: VED "EL HOYO", INSENSATOS!! De Galder Gaztelu-Urrutia y Guión de David Desola y Pedro Rivero [semi-spoilers] Estoy subiendo morralla que se había quedado por mi ordenador. Volveré a subir alguna cosa mejor. Este cuento sin embargo merece un lugar porque no es muy conocido, siendo de quien es, y toca temas que no se suelen tocar tanto el ciencia ficción. El trope de "la habitación cerrada", algo presente en muchos lugares culturales desde la proliferación de Scape Rooms hasta los enigmas de responder "Sí" o "No" (había uno de un tipo en una habitación cerrada sin ventanas ni muebles que se había ahorcado y tenías que averiguar cómo). O sin irnos lejos pero muy forzado, esa movida de las piedras de la India que aparecen dentro de habitaciones sin haber ventanas que comentan en La Mosca y dije que me interesaba. Lo traigo para recomendaros que veáis "El Hoyo". Está genial. Siempre desconfío pero me encantó, no me parece que se posicione políticamente y creo que la construcción fantástica no es nada gratuita, está muy justificada, el guión avanza, las ideas van fluyendo y los debates se van planteándola. No la veáis con las expectativas altísimas porque entonces ya sabéis, pero una peli que se agradece mucho mucho mucho!!!!! Nota: El título de este relato ha ido variando, se público con el nombre (en inglés) La Habitación de bronce cerrada, en 1956 en la revista Magazine of Fantasy and Science Fiction pero en castellano se ha publicado también como "La treta tridimensional" Añado aquí link a una página con pactos con el diablo "reales" auténticos https://www.strambotic.com/sofia/estos-son-los-documentos-reales-de-pactos-con-el-diablo/ La música vuelve a ser nuestro favorito ES5 también conocido como el hombre-máquina Pedro López-Hernández el macgiver del newmedia art, lo generativo, lo procedural y lo estocásticopsicodélico por igual!!! Bravo! jefe! Y al final el main theme de El irishman que es la hostia, me encanta como va bajando la melodía... en la escala pero también en el timbre de los instrumentos... grutal.

fantasy magazine siempre bravo science fiction hern volver asimov cubo el hoyo la habitaci la mosca pedro l pactar nota el es5

[Maupassant] Carta de un loco (1885)

hiring photography themes filter scroll professional development javascript css bouncing js aspect ratios ecmascript es5

Play Episode Listen Later Apr 12, 2020 23:59

Una reflexión romántica sobre los límites de la percepción “Un órgano de más o de menos en nuestra máquina, nos hubiera dado una inteligencia distinta” – Montesquieau Subo este cuento porque ha de estar en esta colección de antecedentes y porque ya lo tenía grabado de hace un año (mísero de mí) pero os urjo aque vayáis a escucharlo en Noviembre Nocturno y después le déis a “El Horla”. [semi-spoilers] Este cuento es un referente antecedente primigenio que había que traer aquí. Lo escribió el autor de “El Horla” un par de años, y yo diría que es como una precuela, o que al menos sirve de base. Pero es que sirve de base para un montón de literatura fantástica que ha venido después. Es un antecedente máximo. Escrito además por un escritor romántico, en una época de invenciones y descubrimientos… Bueno, yo os recomendaría que vayáis a escuchar “El Horla”. No sé si NN y compañía lo han subido ya pero en este caso recomiendo con amor escucharlo con Juan Jose Plans y su equipo de RNE. El programa “Historias”. Buscadlo. Si no conocéis el programa, se os acaba de abrir un mundo de radiodrama maravilloso. Adoro a Juan Jose Plans y los recuerdos de mi escucharlo de pequeño o hace mucho menos tiempo en coche o de viaje están llenos de calor en mi corazón. “Un día me di cuenta de que todo es falso”. Empieza a reflexionar en la frase y empieza a penetrar en él una cierta “claridad” que al poco deriva en oscuridad. Es decir, al convertirse en escéptico, al reconocer lo limitado de los sentidos y la naturaleza constructiva de la percepción, empieza a debilitarse su sentimiento de realidad. Se abre la puerta al brote, a la locura. Cuantas son las historias en las que debido a una revelación el protagonista acaba perdiendo la cabeza. Se está mejor en la ignorancia? Esta vez más que un cuento se trata de un ensayo filosófico-patafísico. ¿Qué pasaría si tuviéramos otros órganos? Por ejemplo un sentido para las variaciones en los campos electromagnéticos. Las palomas ya lo llevan y algunas bacterias se orientan por las líneas Ley o líneas magnéticas. Y si en vez de hechos de CHONPS (Carbono, Hidrógeno, Oxígeno, Nitrógeno , Fósforo y Azufre) estuviéramos hechos de otros elementos, por ejemplo gases nobles invisibles e inodoros? Como dice el cuento, si tuviéramos órganos de más descubriríamos otras cosas, que desconocemos. Realmente conocemos? Estamos rodeados de desconocido. De ahí a la locura hay un paso: puedes asumir que por tanto todo es “inseguro, falso, posible, dudoso”. Me encanta porque el cuento está escrito en la épioca de lauge científico, del newtonianismo – y promulga un relativismo escéptico que es claramente la opción más prudente. Eran los tiempos del descubrimiento del funcionamiento de la electricidad y le magnetismo. El desarrollo del mesmerismo. Mesmer. Lo más magufo divertido que hay por que rezuma un aroma steampunk histórico. Este cuento es un avance intelectual-filosófico fundamental en materia ciencia-ficción, fantasía. Por supuesto que no aporta nada que no haya aportado el pensamiento científico, pero le da forma cultural. Desde el punto de vista del paradigma científico, que trata de describir, explicar y predecir, compone una hipótesis que sólo se puede plantear en el terreno literario. Y es una consecuencia directa del auge del empirismo. Si sólo vale lo “positivo”, es decir aquello que es mensurable, pesable, medible, cuantificable… Qué pasa con todo lo que no se puede medir? Acaso no existe? Claro, no podremos decir nada de ello desde la ciencia… Pero la ciencia misma crea elementos que expliquen esos huecos. Son los tiempos del ÉTER. Hoy tenemos la materia oscura… Este cuento sienta los mecanismos para introducir la fantasía en la prosa realista y autoriza el resto de idas de olla que vengan después. Este cuento tiene que estar asociado a “El Horla” y por favor, acudid a escucharlo, Cuentos que hablen sobre constructivismo y sobre la fantasía de la Percepción he subido alguno. Es que este cuento realmente abre un melón que lo ha impregnado todo posteriormente. De Dick, lo asociaré con La Hormiga Eléctrica, así ha de ser. Además de parte de un directo de Tubular Bells para la BBC de 1973 y un poquito de Riders on the Storm he tenido la suerte de poder usar para ambientar la música de ES5, Pedro López-Hernández, mi jubilado favorito que es precisamente experto en campos electromagnéticos y ondas hertzianas y más allá, y que tanto te programa un instrumento sinéstesico con un nuevo programa que acaba de aprender como transmuta datos fisiológicos en paisajes sonoros, graba en 560mil grados y cinco dimensiones, recoge sonidos fonendoscópicos, dibuja con osciloscopios, crea mallas renderizadas de vectores cuánticos o aprovecha la inteligencia artificial para sus propios menesteres. No estoy de coña! Está muy loco, pero en el buen sentido, no en el del cuento… Podéis ver sus creaciones y buscarle en las redes. Y por supuesto su animal totémico son las salamandras/lagartos y lagartijas! (el escinco es un reptil muy majo). Paz! Ilustración: Rouen

Lambda3 Podcast 140 – Tem que acabar

Lambda3 Podcast

Play Episode Listen Later Apr 26, 2019 77:05

Nós que somos velhos e cansados na tecnologia achamos que algumas coisas já deram, e têm que acabar! Vem com a gente acabar com tudo isso aí! Nesse episódio, que está cheio de itens polêmicos que têm que acabar, o que mais varia é o nível de consenso, tem coisa que todo mundo acha que tem que acabar, e tem outras que nem tanto. Comenta lá embaixo no post do blog se você acha que algo tem que acabar ou não. Lá no final do post tem a lista final dos itens que tem que acabar, se você quiser um spoiler. Fabio, Giovanni e Lucas no estúdio Feed do podcast: www.lambda3.com.br/feed/podcast Feed do podcast somente com episódios técnicos: www.lambda3.com.br/feed/podcast-tecnico Feed do podcast somente com episódios não técnicos: www.lambda3.com.br/feed/podcast-nao-tecnico Links Citados: Episódio do Braincast sobre o que tem que acabar Livro Pensando rápido e devagar Automatic Semicolon Insertion (ASI) Exemplo de Fizzbuzz do Teles Participantes: Fabio Damasceno - @fabiodamasceno Giovanni Bassi - @giovannibassi Lucas Teles - @lucasteles42 Edição: Luppi Arts A lista do que tem que acabar está abaixo. Note que a lista não representa recomendações, é apenas a opinião de quem participou do episódio. Tem que acabar quem olha pra essa lista como uma lista de recomendações! E ajude a contar pra gente o que tem que acabar, incluindo itens e votando nos que já estão lá nesta pesquisa. Scrum Estimativa Projeto em cascata O ; do JavaScript Código em português sem acento Código em português SOAP UI SOAP REST OData Pastel Deploy manual GMUD Microsserviço sem justificativa técnica Profissional DevOps Decisões técnicas tomadas por pessoas não técnicas Gerente de projetos em tecnologia Arquiteto de software sem experiência Desculpa pra não fazer testes Desenvolvedor que só quer codar e não se envolve com o projeto Dev sênior de 2 anos de experiência Teclados não mecânicos Camada de aplicação DDD com receita de bolo Pessoas que não assumem suas decisões técnicas Camadas BOLOVO Cargo Cult Comunicação violenta jQuery Guerrinha de tecnologia (a minha é melhor que a sua) ES5 como target mínimo IE ASP.NET WebForms Emacs Qualquer editor que não suporte modo Vim Procedure no banco de dados Não fazer testes Selenium pra tudo Asserts com APIs que não são fluidas Moq SharePoint on premises ou como portal MVC 5 .NET Framework Commit de binários e componentes Qualquer coisa que não seja Git Framework que faz tudo tipo o Angular Injeção de dependência de construtor Dev que quer pagar hype com dinheiro dos outros Orientação a objetos Linguagens dinâmicas Treta técnica no Twitter On premises Qualquer coisa que não roda em contêineres cmd Twitter Bootstrap Horário não flexível Roupa social no escritório Créditos das músicas usadas neste programa: Music by Kevin MacLeod (incompetech.com) licensed under Creative Commons: By Attribution 3.0 - creativecommons.org/licenses/by/3.0

music nesse kevin macleod vem tem fabio apis acabar comenta braincast fizzbuzz es5 lambda3

Typescript Pain. Is there any Gain?

This Old App

Play Episode Listen Later Apr 15, 2019 33:13

Randy is diving back into the Chasms backend using Firebase Functions, which is written (by him) in Typescript. We discuss the ins and outs as to why Typescript was chosen, some pain points that cropped up along the way, Randy's attempt to rip it out, and ultimately why sticking with Typescript was necessary in this particular case. Alternative episode title: Typescript. Do I need this crap?

pain express javascript node typescript es6 chasms es5

POP! #ES5 "What the Hell’s a Zarginda?"

Everything Sucks PodCast

Play Episode Listen Later Sep 22, 2018

Ken & Julia do commentary on episode 5 "What the Hell’s a Zarginda?" of "Everything Sucks!"#RenewEverythingSucks | #SaveEverythingSucks | SaveBananaSlug @NetflixA list of songs used in episode 5 of "Everything Sucks!" on Netflix.• "Rocket Man"-ELTON JOHN• "Here Comes the Hotstepper"-INI KAMOZE• "Devotion"-CHARIZMA & PEANUT BUTTER WOLFhttps://www.tunefind.com/show/everything-sucks/season-1/57182Please rate us on Itunes!Search on Itunes for "POP Staff"Find us on Face Book athttps://www.facebook.com/groups/ESpodcast/Tweet us@ESPopPodcast or @PKennedyUpdatesor @POPSTAFFTWEETShttps://twitter.com/ESPopPodcasthttps://twitter.com/POPSTAFFTWEETS@popstafftweetsIf you cannot see the audio controls, listen/download the audio file hereDownload (right click, save as)

netflix hell search sucks face book everything sucks peanut butter wolf es5 espodcast popstafftweets

RTO: Using .filter(), Aspect Ratios, Scroll Bouncing…

The Drunken UX Podcast

Play Episode Listen Later Aug 22, 2018 10:18

This week starts with a couple different JavaScript related posts. Our first one looks at how JS dependence is bad for the canned theme market. The second offers an ES5 tutorial on using the .filter()...

Ep. 26 - The Essential Guide to Take-Home Coding Challenges

The freeCodeCamp Podcast

Play Episode Listen Later Apr 16, 2018 28:12

Jane wanted to help others with non-traditional backgrounds succeed on take-home coding challenges. So she wrote an extensive guide for anyone who has received such a challenge and wants to attack it in the best possible way. She divulges mistakes to avoid, how to get organized, and how to go above and beyond. Written by Jane Philipps: https://twitter.com/janephilipps Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2t5215F Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: Introduction Hi, I’m Jane. I wrote this guide because I want to help others with non-traditional backgrounds succeed on take-home coding challenges. Please read it, take notes, apply the material, and let me know about your results. You can reach me via email at jane@fullstackinterviewing.com. This guide is intended for anyone who has received a take-home coding challenge as part of the technical interview process and wants to attack it in the best way. This Essential Guide is a distilled version of a longer Ultimate Guide to Take-home Coding Challenges, which goes into much more detail and walks through an example challenge from start to finish. So, if you’ve just received a challenge and are anxious to get started, start here, and then check out the full guide when you want to learn the material more deeply. Good luck! Mistakes to avoid making when working on a take-home coding challenge There are several mistakes you can make with take-home challenges. Some of these are small mistakes that are easily correctable, while others will leave you frustrated and unable to finish your assignment. I want to address these mistakes first, so when you’re given a take-home challenge, you know exactly what not to do. Here are four mistakes you can make: 1. Time management and scope creep 2. Trying to learn too many new things at once 3. Making too many assumptions 4. Starting to code right away Let’s look at each one in detail. 1. Time management and scope creep Time estimation is one of the hardest problems in programming, and even experienced engineers struggle with it. This plays into take-home challenges in a couple of ways. First, some challenges come with “estimated time.” I usually ignore these, as they are rarely based in reality. Second, some challenges are open-ended. Many people, especially newer developers, will want to add tons of features because they think it will be impressive. Actually, it’s more impressive if you keep the scope relatively narrow, but finish everything you set out to do. In this situation, it’s better to do one thing really well than to do a million things poorly. A good question would be: what counts as “going above and beyond” versus what counts as “scope creep?” My rule of thumb would be if your idea accomplishes or improves on the requirements of the assignment, that is likely a good idea, but if it seems tangentially related or “just cool,” it’s probably scope creep. But, as I describe later, always make it work first. 2. Trying to learn too many new things at once While a take-home coding challenge can be an excellent opportunity for learning, it is possible to take on too much learning. If you’re given a challenge where you must use a specific language or framework, but you’re not familiar with it, don’t add additional complexity by setting out to learn something new on top of that. For example, if you are using a new backend framework for a full stack app, stick to a frontend framework that you’re already comfortable with. If your challenge is language/framework agnostic, but you’ve been itching to try out some new technology, pick JUST ONE to experiment with. Between reading the docs, getting your challenge properly set up, and getting used to any new syntax, you will have your hands full. Even learning one thing will eat up a lot of your time, so I would highly suggest limiting yourself to one new piece of technology per challenge. 3. Making too many assumptions As a developer, if you make too many assumptions, you are bound to build an application where the requirements are off, or the user experience is bad. When given a set of requirements for a take-home challenge, ALWAYS take the time to review the requirements and make sure you fully understand them. And, if you have any questions at all, always ask. First, this shows that you are willing to ask for help when you don’t quite understand something, an important trait for a developer to demonstrate. Second, many companies will intentionally give you product requirements that are vague or not fully fleshed out in order to see how you react in these situations. They are actually testing your ability to make sense of requirements that may have gaps in them. So, when in doubt, ask questions. Asking questions is also a signal that you are engaged and interested in the challenge. 4. Starting to code right away One last mistake you can make is to jump in and start coding right away. I guarantee if you do this, you will regret it. Why? Two reasons: Without proper planning, your code will suffer Without first getting organized and making sure you fully understand ALL of the technical requirements, you may find yourself missing edge cases or rewriting parts of the functionality. I know it seems counter-intuitive, but you will actually SAVE yourself time if you plan ahead. You will spin your wheels trying to get your app set up properly Especially for newer developers, initial app setup can be one of the hardest parts of a take-home coding challenge. It’s not something you do every day, so it often takes some research and reading documentation to get reacquainted with the process and ensure you’re going about it in the best way. So, there you have it — a summary of mistakes to avoid making. You’ll find that a lot of these are also applicable to your day to day work as a developer. In the next section, we’ll dive into further detail on how to get organized before you write a single line of code. Get organized: how to plan before you write a line of code Now it’s time to get to work! But, it’s NOT time to write any code YET. Why? Because, as you’ll see, a lot of the work actually happens before you write a single line of code. This may seem counterintuitive, but again — the more time you spend up front planning, the less time you will spend writing code. So, now you have your coding challenge in hand and you are ready to get started with the planning process. Here are my six suggested steps: 1. Understand the requirements and ask any questions 2. Identify technical decisions you need to make 3. Technical design & whiteboarding 4. Test plan 5. App setup plan 6. Organize your tasks 1. Understand the requirements and ask any questions First, you need to make sure you completely, absolutely, 100% understand the requirements of the project. If any part of the requirements are unclear, it is up to you to reach out to your contact and ask questions. Sometimes companies will purposefully make their requirements vague, in order to see how you approach the problem. In these cases, it is always best to ask questions as it shows you are thinking about the problem and not just making assumptions and building an app to a vague spec. 2. Identify technical decisions you need to make Your next step will be to identify the technical decisions that you need to make. Making a list of all of your technical decisions up front and thinking about them before you’re in the middle of building your app will help you immensely. Not only will it cut down on time figuring things out later, but it will allow you to make big picture decisions up front, as opposed to trying to focus on both the big picture and the small details at the same time. 3. Technical design & whiteboarding Now it’s time to plan out the rest of your app. For anything that you need to draw out, now is the perfect time to do that. Thinking through these decisions at the start serves two purposes: You’ll be able to reference these drawings and your original plan while you’re building your app. Then if you get stuck at any point, you can always come back to your notes. Later, when you are having a discussion with an engineer about your coding challenge, you can use these notes as a reference when they ask you why you made certain design or architecture decisions. Once you’ve thought through and answered some of the bigger design and architecture questions for your challenge, the next step is research. If you’re planning to use a new technology or something you’re a bit rusty with, use this time to search for documentation and other resources. 4. Test plan Another very important step to take before writing a line of code is developing a test plan. Although you won’t get peer feedback on this test plan, it will help you look at the challenge from a different angle, making sure you’re meeting all of the requirements. By thinking through and writing out a test plan before you start coding, you are able to brainstorm possible edge cases that you should account for in your code and you will use this as a basis for testing your app later. 5. App setup plan If you’re starting an app from scratch, figure out if there are any generators you can use to make your app setup easier and faster. Application setup is one of the hardest parts of take-home coding challenges, because it’s something that developers do rather infrequently. Best practices are always changing, so it’s easy to forget how to do. Also, when setting up an app with a specific combination of technologies for the first time, it can be challenging to get everything configured and working together properly. If you are not using a generator, reading documentation and finding working examples are the two most important steps you can take. Being able to play with a working example and compare it to your own app will help you if you get stuck. 6. Organize your tasks The last step before you start coding is to break down and organize your tasks. Breaking down your tasks is essential because it will help you stay on track as you’re working on your challenge, and it will give you a game plan for execution. Note that you shouldn’t be a perfectionist here, because there will always be unexpected bumps in the road. Here is an example task list for a classic Tic Tac Toe app: - Understand requirements - Choose technologies - Brainstorm test plan - Hello World app setup - Build board with HTML/CSS - Implement Tic Tac Toe gameplay with Javascript - Add reset button - Make board responsive - Add ability to add additional boards - Error handling & tests - Code cleanup - README Some of these tasks can be broken down even further into smaller steps. For example, in order to implement the Tic Tac Toe gameplay with Javascript, here are some smaller tasks: - Add a click handler to each square that logs a message - Get click handler to add an X to the square that is clicked - Get clicks to alternate between X and O - Don’t allow a square to be clicked more than once - Implement a function to find the winner and end the game - Handle a tie game 3. Writing tests: just do it! Testing can be overwhelming, because there are so many different types of tests: acceptance tests, integration tests, and unit tests, not to mention test driven development vs. ad hoc testing. Why should you include tests in your take-home coding challenge? It’s simple: your tests will make your submission shine. First, adding tests shows that you know or are willing to learn another technology/framework. It also demonstrates that you take ownership of what you’re building, because you are taking responsibility to make sure it works. Testing also shows that you’ve considered edge cases, which many newer engineers often overlook. Many companies take tests very seriously. Some will not tell you that they expect tests for your coding challenge, but will automatically reject you if you leave them out. Therefore, my recommendation is to write tests no matter what when given a take-home challenge. Not only will it make you a better developer, but for companies that were not expecting tests, you will stand out even more! How do you go about writing a tests? First, create a plan. Here’s my 80/20 suggestion for how to come up with the right test cases: 1. Test the happy path For the classic Tic Tac Toe example, the happy path is starting with an empty board and playing a game until X wins. 2. Think about variations on the happy path A variation on the happy path would be if O wins, or if there is a tie game. 3. Think of edge cases An edge case would be if a player tries to play a move in the same square more than once. 4. Test anything that is complex The algorithm to find the winner is the most complex part of this example. Here’s a sample test plan: - Test that the initial state of the board is correct (i.e. board is visible and empty) - Test that a move can be played - Test that moves alternate between X and O - Test that a move can be played to a square only once - Test that a winner can be found in a row - Test that a winner can be found in a column - Test that a winner can be found in a diagonal - Test that a draw can be found So, now it’s your turn. Think about your app and, as a baseline, think of 5–10 tests that you can write. 4. Make it work, then make it pretty, then make it fast The title of this section sums it up pretty well, but when you’re working on building out your challenge, you should follow these 3 steps IN THIS ORDER: 1. Make it work 2. Make it pretty 3. Make it fast 1. Make it work When you’re given a take-home coding challenge, no matter what you do, the most crucial part of the challenge is to make it work. If you submit an app that has a nice UI, that will not matter if your app does not work or meet all of the requirements. Because building features to spec is a key aspect of your future job as a developer, you first and foremost need to focus on the functionality of your app and prioritize that above all else. This is also key if you are low on or run out of time. Coding challenges can be a lot of work, especially if you want to go above and beyond to ensure that you make it to the next interview round. But, I can guarantee that you will not make it to the next round if your app doesn’t function properly or is missing some key components. So, if you’re building a front-end app, this means focusing on making it work first, and styling/UI last. If you are building a back-end or full-stack app, focus on making it work before trying to refactor your code into the most elegant solution, and only then worry about optimization. Even if you end up without any time to go back and refactor your code or style your UI, having a working app to present is more important. You can always talk to the interviewer about how you would improve your app, and refactoring some of your code might even be part of the next round of interviewing. 2. Make it pretty Make it pretty has two interpretations here. One is making the code pretty, and the other is making the UI pretty. Making the code pretty can be done in several ways. First, ensure indentation is consistent and your code is readable. Second, if you got something to work in a quick, hacky way, think about how you can refactor it to be a more elegant solution without overcomplicating it. If you’re doing a front-end or full-stack challenge, you can also make the UI pretty as part of this step. Whether you use a library or write your own custom styles for your app, making the UI look good will show your interviewer that you’re taking the user experience into consideration when building a feature. For some more front-end-focused challenges, you’ll be given a specific mockup to match. In these cases, making sure you’re detail oriented down to the last pixel is incredibly important. Part of your role may involve translating mockups from designers into user interfaces, so companies want to get a sense of how you approach those types of tasks. 3. Make it fast Once you’ve made your app work, made it pretty (in the code, UI, or both), it may be time to make it fast! This is where understanding performance and BigO notation comes in handy. You should take a look at your code and see if there are any areas where increasing the scale might be an issue. For example, are you using a double for loop somewhere? What if the arrays you’re looping over become super long? If you think about these kinds of edge cases, you can then come up with plan to improve your code. Taking something that would have been running O(n) and making it O(1) will show that you’re thinking about performance when you’re building things. How to make your code shine When given a take-home coding challenge, many people think about how to build an app that works, but stop there. In this section, I’ll go over things an engineer reviewing your code will look for, so you can take your challenge to the next level and make your code shine. When an engineer is reviewing your code, they will look for several different things. They will likely try to run your app to play around with it and see it working. After that, they will delve into the actual code, looking to see how you organized your app architecture and reading code in individual files. There are several things you can do to make your code stand out. You want your code to be: Readable Easy to follow Well organized Clean (properly indented, free of syntax errors and unnecessary whitespace) These are the basics that don’t take much effort outside of mindfulness to get right. Now let’s talk about three of the more involved code style considerations: 1. How to name things 2. How to use comments effectively 3. How to format your code as you write it 1. How to name things Naming is one of the hardest problems in programming. One of the keys to naming things is to make sure you’re naming them in a way that another developer who is unfamiliar with the code can easily jump in and understand. For functions, think about what exactly the function is doing. Is the function checking whether there is a winner on a row of a Tic Tac Toe board? Then a great name would be checkRow. Is your function handling a click on a square of the Tic Tac Toe board? Then a great name would be handleClick. One quick tip: if you find yourself losing your flow because you keep stopping to think of the perfect name, split your process into two steps. First, write working code with any names (like foo, bar, and baz). Then take a second pass through to improve them. 2. How to use comments effectively Adding comments can be a great way to capture what you were thinking at the time you wrote a specific piece of code. This can be useful to you, or anyone else who comes across your code in the future and needs to understand it, tweak it, or rewrite it. Think of comments as adding clarity to your code. But, pay attention, because there is such a thing as too many comments. Here is where you most likely do not need comments: When you declare a variable When you declare a function The variable or function name should be enough to explain exactly what it does. If you need a comment to explain it, then you need to give it a better name! Here are some examples of where comments can be useful: HTML CSS Technically tricky lines of code First, let’s talk about HTML. Markup seems pretty self-explanatory, right? So, why would you need comments? Let’s say you have a really long HTML file with A LOT of s. Comments can be a good way to signal which tags close which sections. In CSS, comments are a good way to divide up your styles if you have a lot of styles in one file. This way, when you come back to the code later and want to make a change, it’s easier to find the styles for that one section you need to update. Comments in CSS are also very useful whenever you are hard-coding any math or adding an arbitrary number of pixels as margin, padding, and so on. Comments can be useful to explain things like this that are specific to your application. One of the best uses for comments is when you’ve written code that is technically difficult or just not intuitive. You should always strive for simple, understandable code as much as possible. However, sometimes you will have confusing code — maybe you’ve chained a bunch of methods together or are using a complex regular expression — and it would help to explain what is happening in a comment. You are almost done learning how to make your code shine! Just one more step. 3. How to format your code as you write it I’m a STICKLER about formatting when it comes to code. And, it’s not just me. You’ll find that the best engineers also care about well-formatted, clean code. Why? First, it’s much easier to read! Coding can be really challenging, so when code is easier to read, it makes our jobs as developers that much easier. Also, writing clean code sends a message to your interviewers that you take pride in the craft of writing code, and for many teams, this is a big deal. So, how do you make sure the code style sticklers will approve of your code? There are a few simple tricks you can use as you’re working through your coding challenge to ensure the end result comes out clean and you don’t have to spend time at the end reformatting everything. Choose tabs or spaces and be consistent across your entire application (i.e. no 2 spaces in some files, 4 spaces in others) Indent your code properly as you go so that it stays readable and isn’t all over the place Get rid of trailing whitespace! Whitespace can sometimes wreck havoc, so it’s best to just get rid of it as you write your code. Keep your syntax consistent throughout your entire app. If you’re using a linter, this will be easier, but requires setting one up. If you don’t have time to set one up, pay attention. Don’t use ES5 in some places in your app and ES6 in others. Pick one and stick with it! Remove unnecessary logging and debug statements when you’re done using them! Unless logging is part of your application, you’ll want to remove any temporary statements you were using while building your app. Always leave a newline at the end of every file That’s it! It’s pretty simple, and once you’re in the habit of doing this, not only will your code be easier for you to read, but it will also be easier for others to read and maintain. Many new developers haven’t been exposed to very much code maintenance, but trust me, when you have to clean up code someone else has written, you will be more thankful if it was neatly organized to start. Pay it forward! How to take your challenge to the next level Here are 3 ideas for how you can take your coding challenge to the next level: 1. Bonuses 2. UI/UX design (for front-end or full-stack challenges) 3. Data validation and error handling 1. Bonuses Not all coding challenges come with bonuses, but if yours does and your goal is to get a job offer, do them! Why? It’s pretty simple. If you go above and beyond in your coding challenge, it will show that you will go above and beyond once you’re hired at this company. Completing bonus requirements is a high competence trigger for the interviewer. 2. UI/UX design (for front-end or full-stack challenges) Some front-end or full-stack challenges will mention UI/UX design as a bonus, but if they don’t, putting in some effort to make the UI look nice and be easy to use will go a long way. You can either go the route of adding your own custom CSS or plugging in a library or two to help make your styling even more painless. If you use a library, just make sure that you understand how it works enough to explain how you’ve used it. 3. Data validation and error handling Data validation and error handling are key components in production apps. Adding either one of these (or both!) to your challenge will help make it stand out. Many developers who are new to coding and haven’t worked in a production codebase before don’t have a ton of exposure to either of these, so if you add error handling for edge cases it will show that you thought through a lot of different situations. How to write an awesome README You may be done writing code, but you’re not done writing yet — it’s time to write your README. Why you should include a README READMEs are incredibly important, both for professional developers and for job seekers working on take-home challenges. Including a README shows that you care about documentation. Documentation helps spread knowledge across teams and serves as a supplement to your code. Having documentation for your take-home challenge ensures that anyone else (or future you) can jump into your code with a clear understanding of what you’ve built without any guessing games. Your README is also the KEY to making sure that everyone reviewing your challenge has the most painless experience possible. Finally, your README is a way of proving to your reviewer that you successfully met the requirements of the challenge. How to write your README Writing a great README is not hard, and you will stand out a great deal from the other applicants with one. Here are the five sections I’d recommend you include: 1. Installation instructions 2. Discussion of technologies used 3. A section demonstrating that you met the requirements 4. If there are bonuses, a section demonstrating that you met them 5. For algorithms and data structures, time and space complexity 1. Installation instructions When writing your README, don’t make any assumptions. Write out all of the steps to run your app locally and test them yourself. This includes cloning the repo from Github, running installation commands, and starting up a server. Also, make sure to include versions of software that you are using. This will ensure that the developer reviewing your code has a seamless experience setting up and running your app, and if they do happen to run into any trouble due to versioning, they will have all of the information they need right there in the README. 2. Discussion of technologies used This section is as simple as it sounds — make a list of all of the technologies you used including frameworks and libraries. If you had to find a library for a specific piece of functionality in your take-home challenge, mention it here and include a link to the docs. 3. A section demonstrating that you met the requirements Usually your take-home challenge will come with some sort of requirements spec, so make sure to include a section in your README where you describe the requirements and how you met them. In some cases, you can take the product spec you were given and write a short explanation of how you met each requirement in a list. In other cases, you can simply include a short paragraph explaining how you satisfied the requirements. It’s totally up to you how you do it, just make sure you include it. 4. If there are bonuses, a section demonstrating that you met them Similar to the requirements section above, you’ll want to highlight any bonuses you completed while working on the take-home challenge. If you attempted a bonus, but couldn’t quite get something to work, then the README is also a good place to address that. You can discuss the approach or approaches you tried and what worked or didn’t work. 5. For algorithms and data structures, time and space complexity If you had to write any algorithms or data structures as part of your take-home challenge, it’s helpful to include the space-time complexity of your final algorithm. This can be done in Big O notation. One final word of advice: write your README in markdown so it looks nice! This will demonstrate that you know (or are willing to learn) another language that will come in handy as a full-time developer. Final steps before you hit send Now that you’ve written your README, you’re almost ready to hit send! Before you do that, take the time to double check all of your work using the following checklist: Re-read the take-home challenge instructions to make sure you didn’t miss any requirements Review your app’s code to ensure that it shines Run your app’s automated tests and make sure they are all passing Test your app manually and make sure everything is working properly Test your app installation instructions from your README Start an email draft and copy your README into it for convenience If requested, make sure to attach a zip file of your code Write an email to your contact at the company Your email can be short and sweet — I always like to highlight something I enjoyed about the challenge or something I learned. Here’s an example: Hi , I hope you had a great week! I had fun diving back into React with this challenge. Here is my Github repo and I’ve included my README below. Please let me know if you have any questions. Just so you know, I’m interviewing with a few other companies and I just received an offer yesterday — I need to get back to them next week. Of course, I am excited about the opportunity at , so I’m looking forward to hearing from you! Thanks, Note that you should only mention interviewing with other companies or offer deadlines if either is actually the case. I feel you should be honest and candid about your situation and maintain leverage for a potential future compensation negotiation at the same time. Now, finally, hit send! Conclusion I hope this Essential Guide was helpful and you learned something that you can apply to a take-home challenge or in your day-to-day work. If you have any comments, questions, or other feedback, please don’t hesitate to reach out. You can reach me at jane@fullstackinterviewing.com.

Thoughts on Angular JS

@DearDanieLim

Play Episode Listen Later Mar 4, 2018 16:24

Random weekend musings on Angular JS, Angular, ES5, ES6, JavaScript and how far we have come since ... !

javascript angular angularjs es6 es5

MAS 021: Lukas Ruebbelke

Play Episode Listen Later Jan 10, 2018 49:08

Panel: Charles Max Wood Guest: Lukas Ruebbelke This week on My My Angular Story, Charles speaks with Lukas Ruebbelke. Lukas is a Google Developer Expert for Angular and Firebase. own a product consultant agency. Lukas also maintains a blog at onehungrymind.com, and is the author of AngularJS In Action. Lukas mentions doing over100 of video for egg.io and many speaking events. Lukas talks about his journey into programming by having an interest in electronics. In high school he learned about low voltage electronics switch led him to learn programming, getting an A-plus certification, and computers. Lukas shares the ideas and path to his successful developer career. In particular, we dive pretty deep on: How did you get into programming? Electronics Partnering in Landscaping Playing with photoshop Went back to college and decided to learn about software programming Learning Flash Java and Compiler ActionScript JavaScript Java and Compiler ES3, ES5 More about learning Flash Server data How did you get into Angular? Focus on learning JavaScript Redux talk Ward Bell, and talking at conferences Running a product consultancy VenturePlex LLC Building App for the market, does that change your approach? and much, much more! Links: onehungrymind.com AngularJS In Action egg.io ventrureplex.com @simpleton Picks Lukas Cole Haan - Grand Crosscourt 2 Tribe of Mentors Cuphead Charles Sega, Atari Knockoffs E Myth Revisited

running playing focus flash panel tribe mentors partnering redux sega java server electronics javascript cuphead landscaping angular e myth revisited firebase compiler google developer expert myth revisited small businesses about actionscript charles max wood es5 ward bell tribe mentors short advice world es3 privcapid lukas ruebbelke

MAS 021: Lukas Ruebbelke

egghead.io developer chats

Play Episode Listen Later Jan 10, 2018 49:08

Panel: Charles Max Wood Guest: Lukas Ruebbelke This week on My My Angular Story, Charles speaks with Lukas Ruebbelke. Lukas is a Google Developer Expert for Angular and Firebase. own a product consultant agency. Lukas also maintains a blog at onehungrymind.com, and is the author of AngularJS In Action. Lukas mentions doing over100 of video for egg.io and many speaking events. Lukas talks about his journey into programming by having an interest in electronics. In high school he learned about low voltage electronics switch led him to learn programming, getting an A-plus certification, and computers. Lukas shares the ideas and path to his successful developer career. In particular, we dive pretty deep on: How did you get into programming? Electronics Partnering in Landscaping Playing with photoshop Went back to college and decided to learn about software programming Learning Flash Java and Compiler ActionScript JavaScript Java and Compiler ES3, ES5 More about learning Flash Server data How did you get into Angular? Focus on learning JavaScript Redux talk Ward Bell, and talking at conferences Running a product consultancy VenturePlex LLC Building App for the market, does that change your approach? and much, much more! Links: onehungrymind.com AngularJS In Action egg.io ventrureplex.com @simpleton Picks Lukas Cole Haan - Grand Crosscourt 2 Tribe of Mentors Cuphead Charles Sega, Atari Knockoffs E Myth Revisited

running playing focus flash panel tribe mentors partnering redux sega java server electronics javascript cuphead landscaping angular e myth revisited firebase compiler google developer expert myth revisited small businesses about actionscript charles max wood es5 ward bell tribe mentors short advice world es3 privcapid lukas ruebbelke

MAS 021: Lukas Ruebbelke

My Angular Story

Play Episode Listen Later Jan 10, 2018 49:08

Panel: Charles Max Wood Guest: Lukas Ruebbelke This week on My My Angular Story, Charles speaks with Lukas Ruebbelke. Lukas is a Google Developer Expert for Angular and Firebase. own a product consultant agency. Lukas also maintains a blog at onehungrymind.com, and is the author of AngularJS In Action. Lukas mentions doing over100 of video for egg.io and many speaking events. Lukas talks about his journey into programming by having an interest in electronics. In high school he learned about low voltage electronics switch led him to learn programming, getting an A-plus certification, and computers. Lukas shares the ideas and path to his successful developer career. In particular, we dive pretty deep on: How did you get into programming? Electronics Partnering in Landscaping Playing with photoshop Went back to college and decided to learn about software programming Learning Flash Java and Compiler ActionScript JavaScript Java and Compiler ES3, ES5 More about learning Flash Server data How did you get into Angular? Focus on learning JavaScript Redux talk Ward Bell, and talking at conferences Running a product consultancy VenturePlex LLC Building App for the market, does that change your approach? and much, much more! Links: onehungrymind.com AngularJS In Action egg.io ventrureplex.com @simpleton Picks Lukas Cole Haan - Grand Crosscourt 2 Tribe of Mentors Cuphead Charles Sega, Atari Knockoffs E Myth Revisited

running playing focus flash panel tribe mentors partnering redux sega java server electronics javascript cuphead landscaping angular e myth revisited firebase compiler google developer expert myth revisited small businesses about actionscript charles max wood es5 ward bell tribe mentors short advice world es3 privcapid lukas ruebbelke

Learning React with Kent C. Dodds

Play Episode Listen Later Dec 29, 2017 35:31

Kent C. Dodds, a leading React expert, speaks with John Lindquist and Joel Hooks, the co-founders of egghead, about how React is a fantastic technology to learn for both newcomers to programming and Javascript grey-beards alike.Kent talks about how great componentizing your code is. No longer are you going in and writing HTML for all your pages, you are now writing powerful and useful javascript components.The concepts that React got built upon don't just apply to React code. Joel talks about how he taught the React style of componentized code, but using Angular in the workshops he has run.Kent and Joel also discuss the importance of ES6. There are still new Javascript tutorials that are get written in ES5, Joel explains why this is shortsighted. The future of Javascript is moving to ES6. Not only that but ES6 is an excellent improvement over ES5.New and powerful features can be leveraged with it, spread syntax, arrow functions, modules. These features are the direction Javascript is moving.So check it out. Learn this new technology and see that it's not so weird, with Kent's new courses The Beginner's Guide to ReactJS and Advanced React Component PatternsTranscript"Learning React with Kent C. Dodds" TranscriptResourcesThe Beginner's Guide to ReactJSAdvanced React Component PatternsLearn ES6codesandbox.ioReact DocumentationKent C. Doddskentcdodds.comTwitterGithubJohn LindquistTwitteregghead.ioGithubWebsiteJoel HooksTwitterWebsite

learning guide beginners kent react javascript html web development angular reactjs es6 kent c dodds es5

075: Babel with Robert Jackson

The Frontside Podcast

Play Episode Listen Later Jul 6, 2017 42:49

Robert Jackson: @rwjblue | rwjblue.com Show Notes: 01:00 - Build Tooling in JavaScript 02:19 - Ember and Babel 07:14 - Deciding on Features 11:46 - Class 13:29 - Workflow 14:39 - Payload Size 15:24 - Config Targets 17:18 - Source Maps 25:05 - Ember Decorators, Objects and ES6 Classes 36:07 - What's next and when can we get it?! Resources: Babel.js esperanto Ember CLI Targets

stage auto figure computers opera square personally deciding babel api promised land safari chrome objects apis javascript firefox css sorcery squares internally partially sauron glimmer grunt json esperanto rfc readme handlebars robert jackson es6 decorators twiddle tc39 frontside ie9 pojo es5 squarehead robert you robert oh chromes robert it charles lowell ember cli turbofan charles you babeljs

046: What's in store for Ember? with Yehuda Katz

The Frontside Podcast

Play Episode Listen Later Nov 9, 2016 50:25

In this episode, Yehuda Katz, co-founder of Tilde, OSS enthusiast, and world traveler, talks about what's in store for Ember. Yehuda Katz: @wycats | blog | GitHub Transcript: ALEX: Hey, everybody. Welcome to the Frontside Podcast, Episode 46. My name is Alex Ford, subbing in for our usual hosts, Brandon and Charles, today. We have an awesome episode. We have a really special treat for you. Co-creator of Ember, Yehuda Katz is joining us today. Hello, Yehuda. YEHUDA: Heyo! ALEX: We also have a first time Frontside podcaster, Chris Freeman. Chris, do you want to introduce yourself? CHRIS: Hey, everybody. ALEX: We've also got a podcast Frontside favorite, Robert DeLuca. ROBERT: Favorite? I don't know if you say that. Hey, everyone. How are you doing? ALEX: I'm really excited about our guest today. Yehuda was just in Austin a couple of days ago. He gave a great meet up talk and a deep dive into Ember and it looks like you're going on-tour with that talk, Yehuda. Is that what I saw from your website schedule? YEHUDA: Yeah, I'm not sure exactly. I change it up every time, largely because things happen. So if I say this thing is 'active' or 'in progress', and then it actually shifts, I have to change it up. I've been talking a little bit about what's up on what we were working on. ALEX: Do you want to give us a brief outline as to what's going on in that talk for those podcast listeners who might not be able to attend? What's going on with Ember? What's new? What is it that you're trying to get across here? YEHUDA: Sure. Actually, the talk I gave in Austin was, you're right, it was basically a deep dive. It was really focusing on a few targeted things that we're working on. I would say that at a high level, we're basically working on a couple of things. One of them is generally more integration with the ecosystem, things like ES6 modules, classes, components that look more like HTML and more graphic components and things like that, also improving EmberCLI so it's more integrated with other tools that people are using. A lot of that stuff has to do with the fact that Ember started a long time ago now, like five years ago or so. And so, I think we've actually done a pretty good job of keeping up with things. For example, we adopted ES6 modules and promises a while ago now, and I think generally speaking, we tend to keep up with the ecosystem. But because we've been around for so long, there are certain things like classes, where it took a while for that feature to catch up with the functionality that we were using in Ember. Decorators landed a little while ago as a stage 2 feature in TC39, and that lets us really take a bigger chunk of the functionality that we have in our class model. I make it work for everybody with class syntax and that's something we're pretty excited about. So that's one area just generally taking things where Ember had its own stuff and try to integrate a better ecosystem. Another big area is this mobile readiness and also, a lot of that has to do with the fact that things like service worker have just recently landed. For example, AppCache was a nice feature in some ways. Some people at Google will kill me for using the word 'nice' in AppCache in the same sentence. [Laughter] YEHUDA: But AppCache was trying to accomplish something for a long time. I think it did some version of what it was trying to do. But really, using AppCache is a default behavior for all users having - there's too many caveats to make it work well where service worker, because it's more of level one and more directly controllable is a better fit for something that we could ship with all Ember users. We basically want to use Ember and EmberCLI, you build an application, you get a good mobile experience out of the box. Some of that has to do with trimming down parts of Ember that we don't need to be using in simple applications. Some of it has to do with service workers, some of it has to do with things like Glimmer 2, just making the performance better. But generally, that's the other [inaudible] so it's basically mobile readiness on the one hand and just integrating better with the one ecosystem are both big picture things we're work on. ALEX: Something that you brought up in your talk where private Ember methods and how a lot of people use private methods and you have to keep them around, what you we're just talking about that was unifying around the conventions of programming in Ember. Whatever JavaScript people bring in to Ember, you want to try to incorporate that as the language moves forward which is, I think, a really interesting problem. Also, something you could talk about a little bit further is what you look for in the way people use Ember going forward and how you have to kind of bend the framework to allow it to be backwards compatible. I'm curious what that decision making is like. YEHUDA: What you're talking about and what I talked about yesterday is what we call 'intimate APIs' and that basically means APIs that we never intended to be public. But for some reason or the other, people got their hands on them and started using them. I gave a somewhat elaborate example of funky case yesterday. But basically, the way we approach generally dealing with compatibility is pretty similar to how the web itself does it. First off, there's a thing that we mark as a public API. We just don't break it unless we make a major version which is very rare. We have basically one of those the entire Ember, and I don't think there's anyone coming in the near future. One option is if we don't like something, we just break it. That's very uncommon. Another option, and this is way more common, is that we try to build -- it's for public APIs -- we try to build a new API and we try to nudge people away from the old one. One approach for nudging that is probably the most common is deprecation. So, deprecations themselves don't violate semantic versioning because we're allowed to say, "Please don't use this anymore." The one area that's annoying about deprecations is that if backup code that powers the old feature has to still stick around. And so something that we've been working on around that aspect, around deprecations is something we called svelte build, which is basically the idea that we'll mark every deprecation with the version, that it will start to be deprecated in and people can ask for, "Please don't include any code that was deprecated out of 2.4, or 2.5, or 2.6, or whatever." Then, we'll automatically slip it away. You could think of it sort of like as a reverse feature flag. CHRIS: Wow, that's actually super interesting. I didn't know that. YEHUDA: We haven't finished it up yet but the RFC that talked about it and actually some old guy who actually wrote the RFC along with 1.13 when I noticed that 2.0 was going to end up being a pretty painful release for a lot of users. We did a lot of things around 2.0 to make things less painful, like we made sure that 1.13 contained all of the deprecations that you could possibly need, as well as all the new features. So if you went to 1.13, you could look at all the deprecation warnings, switch to the new functionality. As long as you have no deprecations left, 2.0 was just the exact same code without any of the deprecated features. But as we're working on that, I realized that there is no real reason to give people such a heartbreak, if we could instead just slip away the code. So that's one approach and I think, more or less deprecations, and then eventually, svelte builds are the normal path. With regard to intimate APIs, those are cases where people came to rely on very specific timing or very specific API, very specific details in some internal API and for those things, if we know that a lot of people use them -- usually they get used to like a couple of add-ons. Maybe Ember Wormhole, which is really popular, we'll use it. Then it's really hard for us to remove those things. Those APIs are harder to maintain compatibility for because the exact details of what they even did was never really well-defined in the first place because they were never documented. So usually what we'll do is we'll look at the usage of the API. We'll come up with a new API that is satisfying the exact same use case, and then we'll deprecate the old API. The policy these days is that you have to go through an LTS release so we'll make sure it's deprecated. Let's say, you want to deprecate something now, make sure it's deprecated in 2.8. And you'll know that if you were actually doing the whole song and dance that deprecate what is intrinsically a private API, so it would be within our rights to say like, "Sorry guys. You used the private API. We're not going to help you." But we really think it's important that for Ember, if something feels like a breaking change, that we're not doing it willy-nilly. If somebody upgrades to 2.9 and all of the sudden, Wormhole stops working, they're not going to understand that the reason that happened was because Wormhole did a bad thing. We basically need to do a clear pass. So we'll do a deprecation in LTS release, then we'll wait a couple of releases before removing it. Then usually what happens is, in the meantime, we'll go ahead and we'll submit pull request for the big add-ons that we're responsible for, and we'll also try to talk and write down why it happened. Historically, we've done that a few times and it's worked okay. There was an example of this, which is the lookup factory API in Ember which is really a boring API but it's used by a bunch of high profile add-ons. So the reasons why we needed to deprecate it were silly. They were just a bunch of bad behavior in the old thing that was making everything super slow. We can make things faster by giving people exactly the same functionality without exactly but identical guarantees. So there were some 'guarantees' which don't even make sense for private API. But there were some things that in theory, the API did that we didn't want to support because of performance reasons. And so, we gave people a new API that is, for all intents and purposes, identical. All users will be able to use it in identical way. But it doesn't have exactly the same weirdness and that weirdness was pretty expensive. ALEX: So you've trained Ember developers to be on the 6-week release cycle? They're looking at the blog posts. They're looking to upgrade but you've been involved in a lot of open source projects where I'm sure that wasn't really the case. Say, jQuery has a huge API and obviously, some things have to be deprecated on that and you were on the jQuery core team, I should mention. YEHUDA: Rails has the same story whereas API releases every year, more or less. ALEX: So, I'm just curious. The fact that you have Ember developers, I would like to think bingeing on your word and hinging on those updates, how would you go about, say, the Rails API? Or the jQuery API? Maybe, now you're involved with Rust, and maybe the plan is to have Rust on a 6-week release cycle. I'm curious, if you don't have your developer's attention, as you do the Ember developers, how do you deprecate an API like that? YEHUDA: That's a good question. How do you deal with deprecations if you're releasing quickly? I think there's a couple of important points to make here. First of all, Rust is on the 6-week release cycle. Sometimes, as the same kind of story with intimate APIs, it's much less common with a strong-type system like Rust. I guess, important things to point out, first of all, deprecations don't intrinsically break things. When we talk about intimate APIs and deprecations happening pretty quickly, those are APIs that are large, if someone is not paying super attention to Ember, they're probably not using those APIs, like they would not have known to use them in the first place. They might be using an add-on that use those APIs and the intimate API deprecation process causes the add-ons to update relatively quickly. In terms of regular deprecations, those deprecations stick around forever so you could come back a year later. For the most part, you could make an app that was 2.2 and upgrade it to 2.9 as long as you upgrade the add-ons that you are using at the same time and everything will work. We also realized that some people can't upgrade every six weeks and that LTS release process which is basically a six-month process, more or less. It basically gives us a communications channel to people who want to pay less attention. The way that that works is that, every four release cycles, so that six times four is 24 weeks -- about half a year. Every 24 weeks, there's another release. We assume people are on that release channel. Some people operate at 2.4, 2.5, 2.6, 2.7, 2.8. Some people go directly from 2.4 to 2.8. For those users, we [inaudible] ecosystem, please make sure you support the last LTS release, which means that if your user's on 2.4, and 2.8 comes around, you know that you could have stuck to 2.4 and generally got add-on support and when 2.8 comes around, you should probably upgrade. Also, with intimate APIs, we make sure we always deprecation them one LTS release before we move into an LTS release. Now, what that means is that if we want to remove something by the 2.8 LTS, we have to have already deprecated it in 2.4. If we want to remove something by 2.12, we have to remove it at 2.8. So six months is still not quite the one-year Rails release cycle but it's starting to get to a reasonable state. Also, I would point out that the LTS releases, the support policy for them is that they're four cycles long. We do bug fix support for six cycles and security releases for 10. What that means is that we're actually supporting LTS releases. We were supporting two at a time for security patches -- two and half basically -- and we're supporting one and half at a time for critical bug fixes. The one and a half basically means that when 2.8 comes out, you have two release cycles which is basically three months to upgrade. If you're on 2.4, and 2.8 comes out, it's not like, "Oh, my God. Panic! I got to upgrade right now." You can take a few months to upgrade. Basically, 2.4 came out, you got all the deprecations you need to care about. You had six months to deal with deprecations and then another three months after that. Even in terms of intimate APIs, where in principle, like Rails and jQuery don't even care about those things for the most part -- ah, jQuery cares about it even more. But most projects will get private APIs and say, "Sorry you used the private API. Why did you do that?" Ember is a rare project in that we actually deprecate things that we know where we actually use them. We have a process for dealing with them. Even that process, like I said, it's not a six-week process. We don't deprecate something and remove it. We deprecate something and then give it a pretty long horizon before removing it. ROBERT: I'm curious. You brought up that you are the common element between jQuery, Rails, and Rust. I know that there are, at least, between Rust and Ember and from Rails to Ember, there have been a lot of commonalities and lessons learned in how the projects themselves are managed. But I'm also curious with Rails, Ember is clearly pretty heavily influenced by Rails, which you were doing before. You've been working on Rust quite a bit and I'm curious, does your usage of Rust, even though it's a very low-level language, does that influence Ember at all? Does that change how you think about the framework or JavaScript in general? YEHUDA: The number one thing that I got out of all those projects that I think used to be a thing is something like a conventional reconfiguration idea which is really not - I think the mentioned of reconfiguration is probably not even the best description of what it is. I think the idea that communities that are all working together on the same thing to build that thing bigger and better and better and better and build ecosystems around that thing, those communities are able to build much higher than communities that ask every single developer to put together a bunch of pieces themselves for profit. That's the basic idea. If you look at Rust, which is conceptually very low-level, you'll find that there are things like Cargo, which is a tool that not only builds your thing and not always package manager but it has a convention -- not only a convention -- it has a built-in support for documentation. So you're on Cargo docs, you get all your documentation for all your dependencies. You run Cargo bench. That's a built-in thing that runs your benchmark. You run Cargo test that runs your test. To mark your documentation as being Rust code, it will automatically run your tests for you when you run Cargo test. We will build your examples for you and make sure your samples keep compiling. There's all this stuff in Cargo that you would not necessarily consider, like it's basic [inaudible] helping you get your workflow the same. Then there's things like Rust format which you've been working on and there's been a huge debate in the community about exactly how much configuration we want to allow in Rust format. But the irony of it is something that most people agree with is that we should try to come up with some kind of default style for Rust that everyone agrees to, that most people can pick up and use the Rust products where it's often used. Then there's things like Futures and [inaudible], where the goal of those libraries is really to make there be a single central way that everybody does [inaudible] in Rust. These are all things that if you look at like C or C++, which are languages that are sort of in the same low-level in this space, in the same kind of area, you'll find that those languages have billions of ways in doing all of those things and there's so many different styles and so many different workflow tools, so many different things that you can make in then a million things that [inaudible]. Even the Rust is conceptually low-level, it doesn't really affecting every single environment as some sort of things that everyone doesn't need to do themselves. I think, an important thing that people don't always get about convention configuration is that it's not just that everybody doesn't have to do all of those things and it saves you some time, it's that when everyone is doing the same thing, it's a lot easier to build another level on top of that. For example, a fast food is a great example of this in Ember. The fact that everyone initializes their application using an Ember initializer, the fact that services were these global things that are sort of global- there's no better word than 'services' but global services, the different components could share the fact that those are all going in the same place. The fact that the way we manipulate DOM is always in a constraint single area. Almost things mean that when it comes out and to build something like fast food, it's pretty easy to take almost any Ember application and make it run in the fast food environment because we know what we're looking at, and that's something that isn't necessarily true about other tools. For me, Chris, the number one thing that, I think, all of those sharing, including jQuery, actually, like jQuery said, "There's so many different ways that people do DOM manipulation, why don't we unify it into one thing that I everyone can use?" You know, the 'jQuery plugin', which is something that has falling out of favor over time. The reason it was so popular was largely because people knew, "Okay, I'm dealing with jQuery object. If I just put a plug into the jQuery object, it makes sense." People understand how to use it. I think that's something that a lot of projects that I used to share and it's also something that is not close to ubiquitous. It's very uncommon, actually. So that's one thing -- the conventional configuration story. I think, another major aspect of all this, and this is something that jQuery and Rails do not share, but Rust and Ember have the RFC process, which more or less, is just a wave as a community of saying, "The way that we agree to add new features to the project is not something coming down the [inaudible] with a tablet every year." At a conferencing, we have agreed to add these features but sometimes people are core team, but sometimes they're not. Sometimes, they're actual contributors, coming with an idea, write their view down in a format that we all know how to do with. Then there's a community discussion about it. Sometimes it takes a very long time. Sometimes it's not. But then we eventually come to a conclusion about what it is that we're doing. Eventually, the core team agrees to merge the RFC. I think one of the nicest things about RFC process is that it produces an artifact that you can come back to a year, two years, three years later. If you say, "Oh, I wonder why they've made that decision. I wonder why that's the thing that they did," and the reason why this is great is that the RFCs are not gospel. They're not something that we should hold onto forever. But at the same time, we don't want to reel it again, things that we already discussed that in-depth over and over and over again. If a person comes back and they say, "Oh, why do they do that? The modification of RFC, why are these instructions directors are like that?" If they go back and look at the RFC and the thread associated with it, and the thing that they want to bring up is something that was already discussed, it's really no reason to bring it up again. But maybe someone have thought of a different idea or a different reason to dislike or to disagree with the decision that was already made. That was already discussed. That's a much better rationale for bringing up for re-litigate. In other words, re-litigating is actually good but if you re-litigating five times a day, on every decision, that's not why you move. So RFCs, by their very nature, the fact that the core team is doing things in public like anybody else and everybody else is also participating in that same process, the fact that artifact tells you, more or less, exactly what was discussed, makes it really easy to decide when is a good time to revisit some of the questions. ALEX: Do you find that poll request has the same process as an RFC and it's an artifact you can go back to, it's a place to have communication that is visible to everybody, unlike say, this micro message service such as Slack where context is just lost for the public. I'm curious if you want to see that modeled in poll requests or if an RFC is where something like that belongs. YEHUDA: I think, poll requests are great. I remember that when I was somewhat like the first user on GitHub who's not a founder of GitHub. I remember one of the things that excited me about GitHub early, although, the very beginning, didn't have poll request yet. but one thing that excite me about poll request is that before poll request, every single time I would use an issue tracker so they were like a billion issue trackers like [inaudible] whatever, and at that time I called it 'patch management'. I want something that helps me manage patches because the actual discussions are not the higher of it. The higher of it is something that submitted a request for me to merge in this patch. How do I merge it? How do I discuss with them? Those things were always really hard so I might ask people to upload patch files or whatever. It's hard to remember how bad things were but the number one thing that was just so obvious but also so terrible about the ecosystem before GitHub was patches were like old mailbox approach. Like you'll make a patch, and hopefully, get it to the right place at the right time. So I think, poll request and comments of poll request and many of the improvements that have been made for poll request are great. The reason, I think, RFC are really important in addition to poll request is that, by the time someone actually took the time to write some code and submit it, it's very easy to look at it and say, "Well, I don't necessary agree on all the things here but I don't want to give a person a hard time that will do the work," whereas somebody submit some idea early on and they say, "I have this idea --" It's actually a lot easier to sort of get into details at that point and say, "Don't do this. If we should do this or it doesn't fit that well with this other RFC or this other poll request that's already open --" But once somebody actually does start and actively working on the feature, I think, poll request are great, like most open source project these days. Ember doesn't ever committed anything to master. Everything goes to poll request, and even core team stuff. I also find that when I submitted a poll request or anybody in the core team, there are almost always people who are not in the core team that saves or fix in the poll request, for various reasons. Of course, poll request also are the usual mechanism by which people run things like CI and linting tools and things like that, called quality tools. I think, the poll request workflow is really good. In terms of other messaging services, I think, there just sometimes the need to have conversations that are faster than poll request and I don't really have any problem with check conversations. But I definitely agree that it has a deep conversation. This is something that happened in the [inaudible] a lot where we having this conversation with the core team and somebody will say like, "We should really move this out into a public discussion, or move it into RFC. If you don't agree with this thing that somebody said public, can you say [inaudible]." So I totally agree that if there's a thing that people want to say in private about something but it's just in private for convenience, it's not private or transient for any good reason, actually getting out there onto the issue or the poll request and say your opinion and letting the conversation back and forth happen there is, for the exact same reason as you said, very useful. In fact, Aaron Turon from Rust brings this point out repeatedly. We just had a conversation this past week about the fact that we have sort of a normal Rust project that, let say in the core team room and it's a technical topic, and it doesn't have anything sensitive about it, people always say like, "Hey, can you move that into Rust Internals," which is a public room. Or like moving this course, we have internals at Rust-Lang.org and I keep thinking Ember could use it. Basically, this sort of a hierarchy of private to public or transient to sort of a free-form discussion forum like this course to something like a GitHub issue, something like an RFC to something like poll request. There's like a hierarchy of how much of those artifacts are easy to search and find. But I think, you're totally right that there's no reason why, things like the core team needs to exist because at some point, the buck has to stop somewhere. Somebody has to make decisions. Somebody has to actually responsible for laying out the cross-cutting vision for the entire project. But those things are actually pretty lightweight. The core team when it's doing its job, it's just sort of making an omnibus of everything that the community is thinking at a particular point and making it more concrete. While, I think that's important that there are spaces which are core team spaces, or spaces that are transient, I think, a lot of questions that people have in the Ember slots are important that people who can just jump in and ask them. I think, getting things out into both public and more of permanent artifacts spaces is good. ALEX: Rob, you are a co-runner of Ember ATX and I was hoping you could speak on the fact that we've gotten some core team members down to Texas to come talk. It's nice that they're able to share their message with what's going on in the core team. But also, they're doing work. They're seeing how real people use Ember and then taking that back to the core team. I was wondering if have just want to comment on that and your work on bringing some really excellent people who make decisions down to Austin. ROBERT: As a meet up runner, like a co-runner, I guess. It's me, Jeff, and Lydia that run Austin Ember ATX. We really like to try and bring people that are deep into Embers core into Austin to talk about the framework that these people work in daily. It's always awesome because whenever you get them there in the flesh, you can ask questions. I guess, we can go back to where Slack is, like you have the higher bandwidth communication but it's even higher bandwidth when you're in person. Getting those people to talk to people that are actually working on the framework daily is I think, hugely important and that's why we work really hard to try and bring out people that work on the core. YEHUDA: For what it's worth, I think that Rails and Ember shares a common core value, like other projects have, more or less. Ember core team people almost exclusively actually work on Ember apps as part of their jobs so I work on skylight. Having some responsibility in the real world for apps that you are working. It's a big difference in just [inaudible]. I definitely noticed a few. Sometimes, I'll be working on a project for a while, like when I was working on Rails for 18 months and never actually used Rails. I mean, I used it but not for anything significant during that time. I, sometimes, get into a rut where I'm working on Ember a lot and I haven't had a chance to work on an app at all. Then, you go back to work on that for a day and it's like, "Oh, my God. There are so many obvious things that I can make better here." Like the kind of things that you would think about when you're working on your framework stuff is not necessarily- as quick it gets, the quickest things that you can fix. The Ember welcome page is a good example of this. I think, when someone is training, it's very easy for them to notice that it would be great if there was some kind of welcome screen for people. But it's not something that a framework author would necessarily think of on your own. Similarly, getting down to places that are not my usual haunts and hearing people bringing stuff that I just hadn't heard before. Like things, "Oh, that's a good idea. But I haven't heard that." A lot of that just come from the fact that the core team has a lot of different kinds of users in it so the people doing training, there are people doing apps or people doing consulting, there are people doing rescue projects in that kind of combos is pretty good. There's a long tale of all kinds of stuff, like people using web sockets for network people using React. People are trying to do Redux in Ember, who knows? That long tale is impossible to represent all that long tale. In a core team, we try to get as much as possible. It's impossible to represent all of them so going out there and talking to people doing weird stuff and weird doesn't meant pejoratively, just unusual stuff. Like Ember, really wants to be pretty flexible under the hood. Even though, it's a pretty conventional tool, we want it to be flexible under the hood so I kind of no way of flexibility is but sometimes, I'll talk to somebody and I'll be like, "Oh, in retrospect, that particular thing, I thought that was flexible as missing as little knob that we can add." So I really enjoy it. CHRIS: Since you've been pretty heads down on Glimmer 2 and you are actually traveling out and talking to people, I'm curious, are you noticing any common themes from the feedback that you're getting recently in terms of what users are saying? Do you have an indication of what the next move might be? Or what people are asking for? YEHUDA: For Glimmer specifically? CHRIS: For Ember in general, or Glimmer specifically. But I imagine, you're probably getting general Ember feedback. YEHUDA: Yeah. I talk about this a little before like the two big areas of interest are mobile readiness and better integration with the ecosystem. Integration is the wrong word. There's nothing wrong with Ember to that extent but people want classes. I think, those are the biggest picture things. I actually noticed a couple, somewhat interesting things when working with Ember. We ship the Glimmer Beta six weeks ago and we're doing another beta just because there's a couple of bugs that we got that were trickling and we want to make sure we get it right. I've actually noticed the people have on the one hand, the story of Glimmer is that we're pretty similar to React in the sense that you should think of what we're doing as a top down, you render the whole time and that there are some nice [inaudible] that use Ember.set or the set API, then we are able to do what people should do with component update automatically for you. For [inaudible], then we know, "Oh, this whole area, doesn't need anything to be updated." If you think about it that way, if you think about it as how can we render [inaudible] around set, I think, you'll notice that Glimmer updates are always faster than React's updates. But people have come to really rely on the sort of quasi-guarantee that if you didn't update something, it doesn't change the DOM associated with it, or even execute code associate with it. I find it sort of interesting. This is like meta problem, which is React actually got some things right about how to make this story performance. Part of that has to do with not assuming that you need as much bookkeeping as Ember always assume that you need. In exchange, you get much faster initial render and you have to do more work around updates. We actually have a pretty good story here. Ember.set is pretty nice because it lets us use API that our users are used to, say, generate [inaudible] upon updates for you and that's nice. But people get very upset when things run that they didn't expect, which of course, is not how React people think about it. The way React people thinking about it is, of course, [inaudible]. That's the whole API. It runs until you told not to. In Ember, things run at people who don't expect to get very angry. I think, you have to be one that I'm thinking about and that's a lower [inaudible]. But in terms of low-level, like thinking about how to shift the mental model of an Ember user so that we can get away with less and less bookkeeping upfront. I still do too much bookkeeping as part of initial render but in order to keep reducing the amount of bookkeeping, we need people to get into mindset of things are fast initially and the tradeoff is that your updates are slower, unless you do whatever. There are mighty things like React does this wasted time debugging tool or they basically tell you, "Hey, you didn't tell us not to render this but it never render," so you should try and do that. To be honest, I think, having to write something once your component updates, that exactly, "Do I [inaudible] is not okay. I'm not willing to do that." But there are a lot of things that approximate that were more similar to Ember existing APIs that we can find. I guess, my medium-term goal here is to make it so that we have the sweet spot so that the initial render is always very efficient. I think, we're getting closer. There's still some back problems that we can deal with so. Initial render is very efficient, fast components are fast, and more or less, you get good updates performance until you reach a certain amount of scale and then the escape valves are much nicer [inaudible] before an update. They're basically little [inaudible] where you say, "You know this thing can't change." It would be hard for me to explain. It would feel like it's [inaudible] we talk about. We've had a bunch of discussion about different escape valves, and the thing I'm most interested in is finding once that feels semantic. Should there a component update doesn't feel like you're describing anything other than React's API. I'm more interested in things that feel like you're talking about your app or your data. ALEX: Yeah. ROBERT: Keeping with the Glimmer 2 topic. Glimmer 2 is written in TypeScript, right? YEHUDA: Yep. ROBERT: Do you see that creeping its way more into the Ember community? I guess, I kind of want to get your general thoughts on TypeScript and what your experience was writing in Glimmer 2. YEHUDA: I actually really like that. But the story with TypeScript was that I was writing the Glimmer 2 originally in regular JavaScript and I came back from a long trip. I want to show Godfrey what I've done and I was having trouble explaining some of the interfaces. I happen to know that TypeScript is a lot of it is just interface so I'll just use their syntax and I think, I open the playground and I type in some TypeScript interfaces. Then I was like, "Oh, it's annoying that if I reload, I'll lose it so let me copy the interface into the ReadMe, basically and to the app." Then over time, like not very much time, I was like, "Oh, it's very annoying that now that I have this, I really wish I could just use it inside of the code." So we started doing that. It took us maybe a week of actually being to be able to use TypeScript for real. But honestly, the code base is pretty big at that point, and the actual was not so bad. A lot of the reason why it was at the time, TypeScripts like VS Code, TypeScript was still younger and it wasn't a slam dunk. For example, in today's TypeScript, you can just have JavaScript files in your directory and just tell it to [inaudible] that works. At that time, you couldn't so you have to really change all the files and there are some things like TypeScript requires you to specify in classes. It requires you to specify all your fields and I think that's fine, that's good for TypeScript. But you're not going to have already done that in JavaScript so you can't just like rename all your JS files with TS and have a nice day. So it took as a little over a week, I think, and we also have to write the Broccoli TypeScript thing during that same period of time. That was another thing we have to do. ROBERT: Yeah, that's a [inaudible]. YEHUDA: Then, with TypeScript change the compiler API a few times so we have a bunch of [inaudible] to do. But other than that initial like [inaudible] to get it working, I would say that it was every single point in time, there was always a [inaudible] win, in terms of what we had to do to make TypeScript happy and what wounds that we got out of it. You get things like, obviously, people know about code completion. I personally like code completion. I think, it's helpful. But I think, jumps to definition is actually more important feature than code completion. Just like what is this method? I want to look at it. You can jump directly to it. Also, for me, the code completion of parameters is way important the code completion of method names so when someone teaches you about code completion, they will usually show you, "Oh, look [inaudible]." It gives you the list of all method names, and you're like, "Well, that's fine. But I probably know all of those method names." But you don't necessarily know all the parameters. Especially, once you start using types, the parameter or information is actually quite rich, like it's telling you this is a component definition, this is a string or this is whatever. All that stuff, I think, I basically come to realize from using TypeScript that Microsoft has done a really good job with [inaudible] code of distilling down to just what part of ID experience is really good and just bring you that to an editor, that feels a lot like Atom or Sublime, or other than that. So if you get like a pretty good ID experience, without all of [inaudible]. ALEX: I've seen some talk on GitHub about people who want to write their Ember add-ons on TypeScript and I did not know Glimmer 2 was written in TypeScript until just now. I'm glad that was brought up. But we as Ember developers have been trained to use convention over configuration. The convention is Ember is not written in TypeScript. We're starting to see convention now where logic has crept into the template, or it's not as much as convention as people are doing it right now. I'm curious what your thoughts on that and more is treating Handlebars as a programming language and something that we're seeing now in real production Ember code, so what is the path going forward there because it is happening? YEHUDA: Yeah, I agree. I just want to say, I didn't actually answer the previous question in full. I think my expectation is we have no interest in ever making TypeScript as rudimentary part of Ember. I think Ember should always work and work nicely with regular JavaScript. I don't want to do anything that would lean to heavily on people having TypeScript around. Certainly, I don't want to do with Angular did, which they use the types as semantic markers for dependency injection and something like that. But I do anticipate things like Ember-metal for sure, Ember runtime being written in TypeScript because anything that's pretty low-level and a lot of algorithms benefits a lot from clearly delineating interfaces. I think, another thing people don't realize is that there are all these [inaudible] interfaces floating around your code in JavaScript. But like you are in a class, it's pretty easy to document what the class does. But if you have an interface, it's not really any good mechanism for describing it and it can become very [inaudible] and it's Like, "Please give me an object as these methods on it and build these methods." It's funny because you don't realize until you start using TypeScript that it's a very recursive problem. It's like, it has these three methods on it have these six parameters and these parameters have these interfaces and those have these. So you can actually start describing a very complicated thing and it's like those complicated things didn't exist before, they were just very implicit. The explicitness of the interfaces is not you can write [inaudible]. You can write the three interfaces and have the methods with all types of networks [inaudible]. I think, I expect Ember-metal, Ember runtime, other low-level parts Ember, certainly the component library now it's like directly linking in with Glimmer and Glimmer were written in TypeScript so that stuff would really benefit with TypeScript. In terms of Ember itself, using TypeScript, I think we have sort of a medium term goal of letting Ember apps use TypeScript if they want. I would say that making that story really nice, pretty much leans on ES6 modules and ES6 classes so we have some of the ES6 modules but there's still a lot of Ember [inaudible] whenever module story. In terms of classes, were still using the old-style class system and that class system is actually just really hard to get the types working in TypeScript. It's hard, period. But like React has a similar problem and there's lot of advance features that only really exists in [inaudible] express ES5 class [inaudible] and TypeScript doesn't have all the features. My expectation is that sort of along the same path as getting ES6 classes. We will also get a lot of TypeScript support in Ember and I think a lot of people are interested. A lot of people have work on Glimmer now and they're like, "I would love to use it in my app so we'll probably have that happen." Coding your templates, was the other question. I sort of have a mixed feeling about this because on the one hand, I actually do want Glimmer to be the programming language in production way. So either templating engines are just using the programming language embedded like the ERP. Or they are like Mustache or like the general templating engine -- forget what that thing is called -- but there's a bunch of template engines that use like the curly syntax and those things aren't very rigorous in terms of how they think about scope. Like lexical scope, it turns out to be a pretty important thing about how programming language work. If you have a shitty scope story, people don't have a good sense of what's going on so like the Angular 1 templating story was you basically find your scope on wherever and you attach to a part of your template and that basically means that if you're looking at just temple, you have no idea what the actual variables mean, anyway, because any part of it could be choking up the scope to be whatever. I start with Handlebars but have refined a lot overtime and I'm pretty happy with it now. The Glimmer templating engine is basically defines a programming language. It has scoping story. If you want a variable, name it. Use the as-pipes syntax and you get some variables there. Your function, your output, your components, and your helpers are functions and sometimes it's written in JavaScript, just like in Ruby cellular functions that are written in C. But ultimately, just like a C extension, it can't magically change the scope of Ruby program, helper or component in Glimmer. It can't magically change the scope of your template. With all that needs, if you look at a Glimmer template, it's actually really clear what are the names mean. That sound boring but ultimately, that's one of the things that needs to you look up at a lot templating engine and not only really know what's going on. I don't understand what's going on, without thinking of what every single one of those custom helpers is doing. I think Jinja is the name of the templating engine in Django. If you look at some of the templating engine like that or even like Handlebars before Ember 2.0, you really have to go that like 'for x and y' is a magic syntax that needs a particular thing. Because a lot of these templating engines are very flexible in the sense that they let users have or whatever, any particular piece of syntax could actually be creating random names that mean whatever. I've just found, having worked through that in the Ember community, I'm very happy that we took the time to get that stuff solid. One of the nice side effects of that is that it makes some of the usual optimizations that people do on code work very nicely. Once we know all the names mean and know all the scopes mean, things like in lining specialization from invocation. This component is invoked here. It has these parameters, but those parameters are all strings and I can see the receiving end. The receiving end just fix those strings into attributes or something. At compilation time, like to combine all into one thing. This is an optimization that we haven't done yet because we been working on compatibility. But there's a lot of normal 'programming languages standard optimizations' that we can do because we design Glimmer to be a programming language. The fact that we've done that is actually mean the root cause of people doing more programming language stuff in their templates, in older versions of Ember before, we had done such a good job of rationalizing everything. You would start doing that stuff and you would start hitting clips where the behavior didn't work the way expected for some reason, then you just use a sub-expression as something and then depending on exactly which things you put into the slots, maybe it didn't update on the inside of the template. We always consider those things as bugs so we would fix the bugs that we encountered. There's an explosion of different kinds of things in a programming language and if you don't model variables as variables basically, then it's hard to know callbacks are callbacks, variables as variables. There's a lot of doubt so they would start using the APIs as part of them [inaudible] hit someone and they would pull back. But today, the implementation of Glimmer, especially with Glimmer 2 is extremely [inaudible] standard, and what that means is that you want to do very [inaudible], parenthesized expressions with as type something and then you want to go and take that and send to the component and you have that and you put that value and put it to a service and you do all that and it works. That doesn't necessarily mean that it's a good idea for your template to be in a large program. That's generally that. I think that's main question that you asked me and it is generally, for things to get really complicated. But I think there is a reason for it and I think it's something we're doing to make it better. I think, the reason for it is that, if you think about the Glimmer core language, the main escape of what you have to get complicated expressions out of Glimmer and back into a reasonable place is helpers. Let's say you have a big bunch of [inaudible], and/or whatever people are doing inside of their Glimmer templates and it's like a multi-line thing and you want to pull that out to a more reasonable place. The natural way to do that is to make a helper. But it's also pretty common that you have a complicated piece of expression that isn't reusable. It's not being reusable for multiple places and helpers in Ember right now are global so you may have this big block. Another [inaudible] of computer's property, but computer property's don't have a nice- like I have a few internal parameters and I just do something that they always require you do something against it, the components off of this, and that is usually what's you are doing. You're usually have what is effectively a function with a bunch of parameters in it and those parameters combine some way like with 'and', 'or', maybe there's some comparisons like 'greater' or 'less than' or whatever. One of the things that comes out of module modification RFC and makes everyone pretty excited is the ability to have helpers in your templates that are local so it's a helper that is just sitting right next to your template. I think, those kind of things -- helpers that are right next to your template -- will give people who like you do not want to see so much code in your template, a much nicer story to explain to people why we're doing it, and what we should do instead. A template has a three-line, fifteen is privacy expression and you want to convince the person not to do it. The re-factor is literally just to make a local helper, put the code in there and use the local helper. I think that's the better story to explain to people than, "Hey, I don't like that. It feels bad. What should I do?" CHRIS: This brings up an interesting point that we actually encountered recently at The Frontside, we use helpers a lot and are frequently trying to get them to do all sorts of weird things. But recently, it occurred to us that one kind of blocker was that you can't compose helpers. We had an existing helper and we kind of needed to make a helper on top of it and it suddenly dawned on all of us that, "Oh, we can't go up a level." We can't build a helper and its abstraction over another one because you kind of have to hit the dump. You have to have a component or a template or something to invoke that. Is that's true? YEHUDA: I would expect that you could call the function with the arguments that looked ugly but I would suspect and I would say that you can call it and just pass the parameters and hash these [inaudible] and -- ALEX: Like a helper that invoke or something? Because to write a new helper, you would have to go back to JavaScript. YEHUDA: That array an object. I expect that to work. Do you just need a helper calling another helper? ALEX: Well, a helper composing, like composing several helpers into a bigger helper and then just calling in the template, much like how you might write some functions and that write a function that closes over them or something. YEHUDA: Are we talking about a helper that takes the helper? ALEX: I guess it could be. I guess, higher order helpers could be a thing in this case. YEHUDA: Helpers that call helpers are helpers that close over helpers really should just- helpers are more or less functions. It would just be able to use them directly. I think, what you're saying is an interesting Ember phenomenon. I actually don't know which of two categories this discussion is in. Basically, either. Either there is some good reason why this turns out to be difficult and there's like a missing API that usually fix it. Like in general, my mental model here is you're talking about a function so if you can just [inaudible] the function, it really should work and in that, it is hard. There's something weird. Basically, what I'm saying is either there are some 'gotcha' that how it was structured right now, that's like an accident. That means they're not exactly as much like functions as we think or the mental model that you have using them doesn't make you think of them like functions. So you think that there are hard to compose but actually there are functions. Basically, those two things are equally likely Ember. I think that's unfortunate. ALEX: I think that with them, you can certainly combine them in a template and you could even pass one into the other. What we ran into an issue was, similar to functions, if you are writing like an npm library, you may write five functions and only export one of them. That one function will compose the other four and call them. In some cases, you may not realize, do you want to export that composed abstracted function until much later and it's okay, because you just import the function from somewhere else, then you say like, "All right. I'm just going to consume this function from another and now I have this combination put together." Well, with a helper, if you already have a helper that does something and then you realized, "Oh, actually, I need to build an abstraction on top of this helper in a new helper," we so far have not found a good way to combine them like that. YEHUDA: So probably, it will not succeed and having this conversation through to the completion year. I'll just say for listeners, what I find surprising about this, although, I can believe that there is something that makes it true is that helpers in Ember are really just functions and increasingly they really are like helpers in Glimmer are functions. They have a weird arguments signature. They take positional parenthesis in array and named arguments as dictionary and that's a convenience basically because otherwise, you have to scrape of the last parameter and try to figure stuff out. So that's a signature issue. But generally speaking, helpers are supposed to be functions and if there's something that you could do with regular functions you can't do them with helpers, that sounds to me like something is wrong. Like I said, I can definitely believe I should talk to Chris about this and he should write a blog post about it. I can definitely believe that there is something that makes it true but it's hard for me to imagine what it is. CHRIS: Well, I'm glad to talk to you about it offline. YEHUDA: Yes. We will figured it out. ALEX: Yehuda, thank you for this deep dive into open source process into Ember. I could drill deeper into your brain and just extract as much knowledge as I can. I hope to be able to do that someday soon. We're going to wrap up for today. Thank you very much for Yehuda Katz and your time. YEHUDA: Yeah. Thank you. I apologize for people who didn't understand half the things I said. ALEX: Yeah, it's a podcast for everybody. But we have a lot of Ember developer's listening and I'm sure that they loved it and hated it all up so thank you very much.

god texas google microsoft id panic integration dom react slack futures initial rust historically api redux coding github cargo apis javascript sublime mustaches atom html rails erp ts godfrey django oss js wormholes glimmer embers angular typescript jquery vs code rfc readme lts handlebars tilde es6 jinja decorators chris freeman rfcs tc39 frontside chris well yehuda katz alex so es5 alex yeah alex ford alex do robert do rails api appcache alex rob robert deluca

51: Is Liking ES5 Normal?

Does Not Compute

Play Episode Listen Later Sep 27, 2016 24:05

In episode 51 of Does Not Compute, Sean and Paul talk about GitHub and GitLab's new project management features, GitHub's recent decision to use GraphQL, and if its ok to like ES5 over ES6

normal github liking gitlab graphql es6 es5 does not compute

103 AiA New Developer Problems

Play Episode Listen Later Jul 28, 2016 60:37

Angular Remote Conf This show is based off the following listener email: “I know you've discussed a couple of times about how hard it is to set up an Angular 2 project. Whilst most of this has nothing to do with Angular itself, it's still the barrier to entry. There's no point in saying how much easier Angular 2 is than Angular 1 if you can't get it running. Even though I'd heard your previous discussions on this, in reality I was totally unprepared as to how difficult it was when I had to do it myself recently. Even the Angular 2 5 minute quick start took me a day to get my head around! I was delighted to hear the Angular team was coming up with Angular CLI. Get the mechanics out the way and lower the barrier to entry. So I typed 'ng new myapp'. Oh! Looking at the properties of the directory I saw Size: 161MB, Contains: 40,531 files, 7,226 folders. Has the JavaScript world gone completely mad? Is this really acceptable? 40,000+ files before I write my first line of code? OK, so Angular CLI has created all this stuff for me but I still have to understand what it's about, or how will I maintain it and keep it up-to-date. What happens if there's an incompatibility in one of the libraries used? It would be great to hear the members of the podcast discuss what they think needs to happen in order to simplify this. Is Angular CLI actually simplifying things, or is it just shifting the 'getting starting' problem to become a maintenance problem? Is it even possible to have a simple Angular 2 project, do we need to just accept that 161MB of disk space is a minimum? Has Angular 2 become out of reach for hobbyists, or is it the exclusive property of experts and full time client-side developers only?” 04:35 - Purpose and Value 15:32 - “Dumpster Fire” 19:01 - Capability and Complexity 26:03 - Getting Setup to Develop in Angular; Investing in Skills Angular 2 5 Min Quickstart Tour of Heroes Tutorial “Has Angular 2 become out of reach for hobbyists, or is it the exclusive property of experts and full time client-side developers only?” Lukas Reubbelke: Angular 2 with Handcrafted Tools, Century-Old Techniques and ES5 Picks Chaos Monkeys: Obscene Fortune and Random Failure in Silicon Valley by Antonio Garcia Martinez (Ward) Wink (Lukas) Badass: Making Users Awesome by Kathy Sierra (Lukas) Learning (Joe) George W. Bush in Dallas: “Too often we judge other groups by their worst examples, while judging ourselves by our best intentions.” (Joe) VidAngel (Joe) Opposing protesters meet in Dallas (Chuck) iPad Pro (Chuck) Apple Pencil (Chuck) GoodNotes (Chuck) Adventures in Angular Facebook Page (Chuck)

tour investing adventures skills silicon valley develop bush ward developers complexity george w bush javascript ipad pro dumpster fire opposing wink capability angular apple pencil vidangel goodnotes antonio garcia martinez kathy sierra angular cli es5 random failure chaos monkeys obscene fortune angular remote conf badass making awesome kathy sierra heroes tutorial

103 AiA New Developer Problems

Play Episode Listen Later Jul 28, 2016 60:37

Angular Remote Conf This show is based off the following listener email: “I know you've discussed a couple of times about how hard it is to set up an Angular 2 project. Whilst most of this has nothing to do with Angular itself, it's still the barrier to entry. There's no point in saying how much easier Angular 2 is than Angular 1 if you can't get it running. Even though I'd heard your previous discussions on this, in reality I was totally unprepared as to how difficult it was when I had to do it myself recently. Even the Angular 2 5 minute quick start took me a day to get my head around! I was delighted to hear the Angular team was coming up with Angular CLI. Get the mechanics out the way and lower the barrier to entry. So I typed 'ng new myapp'. Oh! Looking at the properties of the directory I saw Size: 161MB, Contains: 40,531 files, 7,226 folders. Has the JavaScript world gone completely mad? Is this really acceptable? 40,000+ files before I write my first line of code? OK, so Angular CLI has created all this stuff for me but I still have to understand what it's about, or how will I maintain it and keep it up-to-date. What happens if there's an incompatibility in one of the libraries used? It would be great to hear the members of the podcast discuss what they think needs to happen in order to simplify this. Is Angular CLI actually simplifying things, or is it just shifting the 'getting starting' problem to become a maintenance problem? Is it even possible to have a simple Angular 2 project, do we need to just accept that 161MB of disk space is a minimum? Has Angular 2 become out of reach for hobbyists, or is it the exclusive property of experts and full time client-side developers only?” 04:35 - Purpose and Value 15:32 - “Dumpster Fire” 19:01 - Capability and Complexity 26:03 - Getting Setup to Develop in Angular; Investing in Skills Angular 2 5 Min Quickstart Tour of Heroes Tutorial “Has Angular 2 become out of reach for hobbyists, or is it the exclusive property of experts and full time client-side developers only?” Lukas Reubbelke: Angular 2 with Handcrafted Tools, Century-Old Techniques and ES5 Picks Chaos Monkeys: Obscene Fortune and Random Failure in Silicon Valley by Antonio Garcia Martinez (Ward) Wink (Lukas) Badass: Making Users Awesome by Kathy Sierra (Lukas) Learning (Joe) George W. Bush in Dallas: “Too often we judge other groups by their worst examples, while judging ourselves by our best intentions.” (Joe) VidAngel (Joe) Opposing protesters meet in Dallas (Chuck) iPad Pro (Chuck) Apple Pencil (Chuck) GoodNotes (Chuck) Adventures in Angular Facebook Page (Chuck)

tour investing adventures skills silicon valley develop bush ward developers complexity george w bush javascript ipad pro dumpster fire opposing wink capability angular apple pencil vidangel goodnotes antonio garcia martinez kathy sierra angular cli es5 random failure chaos monkeys obscene fortune angular remote conf badass making awesome kathy sierra heroes tutorial

103 AiA New Developer Problems

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Jul 28, 2016 60:37

Angular Remote Conf This show is based off the following listener email: “I know you've discussed a couple of times about how hard it is to set up an Angular 2 project. Whilst most of this has nothing to do with Angular itself, it's still the barrier to entry. There's no point in saying how much easier Angular 2 is than Angular 1 if you can't get it running. Even though I'd heard your previous discussions on this, in reality I was totally unprepared as to how difficult it was when I had to do it myself recently. Even the Angular 2 5 minute quick start took me a day to get my head around! I was delighted to hear the Angular team was coming up with Angular CLI. Get the mechanics out the way and lower the barrier to entry. So I typed 'ng new myapp'. Oh! Looking at the properties of the directory I saw Size: 161MB, Contains: 40,531 files, 7,226 folders. Has the JavaScript world gone completely mad? Is this really acceptable? 40,000+ files before I write my first line of code? OK, so Angular CLI has created all this stuff for me but I still have to understand what it's about, or how will I maintain it and keep it up-to-date. What happens if there's an incompatibility in one of the libraries used? It would be great to hear the members of the podcast discuss what they think needs to happen in order to simplify this. Is Angular CLI actually simplifying things, or is it just shifting the 'getting starting' problem to become a maintenance problem? Is it even possible to have a simple Angular 2 project, do we need to just accept that 161MB of disk space is a minimum? Has Angular 2 become out of reach for hobbyists, or is it the exclusive property of experts and full time client-side developers only?” 04:35 - Purpose and Value 15:32 - “Dumpster Fire” 19:01 - Capability and Complexity 26:03 - Getting Setup to Develop in Angular; Investing in Skills Angular 2 5 Min Quickstart Tour of Heroes Tutorial “Has Angular 2 become out of reach for hobbyists, or is it the exclusive property of experts and full time client-side developers only?” Lukas Reubbelke: Angular 2 with Handcrafted Tools, Century-Old Techniques and ES5 Picks Chaos Monkeys: Obscene Fortune and Random Failure in Silicon Valley by Antonio Garcia Martinez (Ward) Wink (Lukas) Badass: Making Users Awesome by Kathy Sierra (Lukas) Learning (Joe) George W. Bush in Dallas: “Too often we judge other groups by their worst examples, while judging ourselves by our best intentions.” (Joe) VidAngel (Joe) Opposing protesters meet in Dallas (Chuck) iPad Pro (Chuck) Apple Pencil (Chuck) GoodNotes (Chuck) Adventures in Angular Facebook Page (Chuck)

tour investing adventures skills silicon valley develop bush ward developers complexity george w bush javascript ipad pro dumpster fire opposing wink capability angular apple pencil vidangel goodnotes antonio garcia martinez kathy sierra angular cli es5 random failure chaos monkeys obscene fortune angular remote conf badass making awesome kathy sierra heroes tutorial

203 JSJ Aurelia with Rob Eisenberg

Play Episode Listen Later Mar 16, 2016 71:07

Check out React Remote Conf! 02:31 - Rob Eisenberg Introduction Twitter GitHub Blog 02:55 - Aurelia Blog 03:43 - Selling People on Aurelia vs Other Frameworks 11:09 - Using Aurelia Without Directly Engaging with the API Web Components 15:10 - Production Usage 18:46 - Specific Uses 23:03 - Durandal 25:26 - Aurelia and Angular 2 30:32 - Convention Over Configuration 34:56 - Web Components Content Projection (Transclusion) Polymer 41:13 - One-directional Data Flow; Data Binding Using a Binding System as Messaging System 46:55 - Routing 49:47 - Animation 52:56 - Code Size 55:06 - Version Support 56:27 - Performance Tools 01:00:20 - Aurelia in ES5 01:01:29 - Data Management Breeze.js Picks Crispy Bacon (Joe) A Gentleman’s Guide to Love and Murder (Joe) Jamison Dance: Rethinking All Practices: Building Applications in Elm @ React.js Conf 2016 (Joe) Vessel | Lorn (Jamison) The Moon Rang Like a Bell | Hundred Waters (Jamison) The Top 10 Episodes of JavaScript Jabber (Chuck) Amazon Prime (Chuck) WiiU (Chuck) Sketch (Rob) Zeplin (Rob) servo (Rob)

love guide performance murder tools blog amazon prime animation api gentleman conf github sketch breeze wii u data management angular routing polymer web components dataflow zeplin durandal javascript jabber es5 data binding rob eisenberg other frameworks react remote conf eisenbergeffect rob eisenberg introduction

203 JSJ Aurelia with Rob Eisenberg

Play Episode Listen Later Mar 16, 2016 71:07

Check out React Remote Conf! 02:31 - Rob Eisenberg Introduction Twitter GitHub Blog 02:55 - Aurelia Blog 03:43 - Selling People on Aurelia vs Other Frameworks 11:09 - Using Aurelia Without Directly Engaging with the API Web Components 15:10 - Production Usage 18:46 - Specific Uses 23:03 - Durandal 25:26 - Aurelia and Angular 2 30:32 - Convention Over Configuration 34:56 - Web Components Content Projection (Transclusion) Polymer 41:13 - One-directional Data Flow; Data Binding Using a Binding System as Messaging System 46:55 - Routing 49:47 - Animation 52:56 - Code Size 55:06 - Version Support 56:27 - Performance Tools 01:00:20 - Aurelia in ES5 01:01:29 - Data Management Breeze.js Picks Crispy Bacon (Joe) A Gentleman’s Guide to Love and Murder (Joe) Jamison Dance: Rethinking All Practices: Building Applications in Elm @ React.js Conf 2016 (Joe) Vessel | Lorn (Jamison) The Moon Rang Like a Bell | Hundred Waters (Jamison) The Top 10 Episodes of JavaScript Jabber (Chuck) Amazon Prime (Chuck) WiiU (Chuck) Sketch (Rob) Zeplin (Rob) servo (Rob)

love guide performance murder tools blog amazon prime animation api gentleman conf github sketch breeze wii u data management angular routing polymer web components dataflow zeplin durandal javascript jabber es5 data binding rob eisenberg other frameworks react remote conf eisenbergeffect rob eisenberg introduction

203 JSJ Aurelia with Rob Eisenberg

JavaScript Jabber

Play Episode Listen Later Mar 16, 2016 71:07

Check out React Remote Conf! 02:31 - Rob Eisenberg Introduction Twitter GitHub Blog 02:55 - Aurelia Blog 03:43 - Selling People on Aurelia vs Other Frameworks 11:09 - Using Aurelia Without Directly Engaging with the API Web Components 15:10 - Production Usage 18:46 - Specific Uses 23:03 - Durandal 25:26 - Aurelia and Angular 2 30:32 - Convention Over Configuration 34:56 - Web Components Content Projection (Transclusion) Polymer 41:13 - One-directional Data Flow; Data Binding Using a Binding System as Messaging System 46:55 - Routing 49:47 - Animation 52:56 - Code Size 55:06 - Version Support 56:27 - Performance Tools 01:00:20 - Aurelia in ES5 01:01:29 - Data Management Breeze.js Picks Crispy Bacon (Joe) A Gentleman’s Guide to Love and Murder (Joe) Jamison Dance: Rethinking All Practices: Building Applications in Elm @ React.js Conf 2016 (Joe) Vessel | Lorn (Jamison) The Moon Rang Like a Bell | Hundred Waters (Jamison) The Top 10 Episodes of JavaScript Jabber (Chuck) Amazon Prime (Chuck) WiiU (Chuck) Sketch (Rob) Zeplin (Rob) servo (Rob)

love guide performance murder tools blog amazon prime animation api gentleman conf github sketch breeze wii u data management angular routing polymer web components dataflow zeplin durandal javascript jabber es5 data binding rob eisenberg other frameworks react remote conf eisenbergeffect rob eisenberg introduction

50 ngAir - TypeScript Deep Dive with Alex Eagle and Blake Embrey

Angular Air

Play Episode Listen Later Feb 5, 2016 58:19

TypeScript Deep Dive with Alex Eagle and Blake Embrey Sure, you can write Angular 2 in ES6 with Babel or even ES5, but most developers that try out TypeScript with Angular 2 never look back. Alex Eagle is on the Angular core team at Google and has been doing a lot of work to make sure Angular 2 works well with TypeScript. Blake Embrey is the creator of ts-node and a huge TypeScript enthusiast. Even if you have concerns about typing in JavaScript, listen to this episode to get the low down on why TypeScript rocks and how it is going to help you to build awesome apps in Angular 2. Picks • Alex Eagle http://www.typescriptlang.org/Playground https://basarat.gitbooks.io/typescript/content/ [TrumpScript] (https://github.com/samshadwell/TrumpScript) [Broccoli] (http://broccolijs.com) [ts-node] (https://github.com/TypeStrong/ts-node) • Olivier Combe Links: Managing state in Angular 2 applications by Victor Savking: http://victorsavkin.com/post/137821436516/managing-state-in-angular-2-applications Tips:PhantomJS 2.1 has been released (1 year after 2.0), it’s time to upgrade • Jeff Whelpley Tips:Try TypeScript Picks: ▪ Angular Air episode 50! ▪ [Learn Angular Universal on Read the Source] ▪ (http://hangouts.readthesource.io/hangouts/angular-universal/) [Nathan Walker and Angular CLI changes for 3rd party libs] (https://github.com/angular/angular-cli/pull/135) [Front end dev resources] (https://github.com/dmytroyarmak/frontend-dev-resources) Patrick Stapleton Tips:Provide feedback on problems you ran into for open-source projects. Picks: [Typings with Blake Embrey] (https://plus.google.com/events/c6sv2k75vi9q8fj0g0gkuqbt69o) [Learn TypeScript free workshop by Blake Embrey] (https://github.com/TypeStrong/learn-typescript) • Ari Lerner Tips: Picks: [The Barisieur] (http://www.joshrenoufdesign.com/new-gallery-5/av7fqhie9y5ptdbxr9s4i8rb65irqo) [Activitaté] (http://www.withings.com/us/en/products/activite [Withings Aura] (https://www.withings.com/us/en/store/details/70035401) [Modern Romance] (http://www.amazon.com/Modern-Romance-Aziz-Ansari/dp/1594206279) Blake Embrey Tips:If you have issues, create issues, but remember to keep things actionableLearn TypeScript (or another typed language) and think about where else you could be applying type system semantics Picks: Reading everyday, before bed Currently reading: https://www.goodreads.com/book/show/6065215-the-strain Forgot to mention on the show, but meetup! http://www.meetup.com/hello-world-sf/Angular Air is a video podcast all about Angular hosted by Jeff Whelpley. Please visit the Angular Air website (http://angularair.com) to see upcoming and past episodes. Also be sure to follow Angular Air on Twitter and Google+ to stay up to date with future episodes. Also, all episodes are on the YouTube channel as well. AngularClass Learn AngularJS, Angular 2, and Modern Web Development form the best. Looking for corporate Angular training, want to host us, or Angular consulting? twitter: @AngularClass email: info@angularclass.com chat: Join AngularClass Chat --- Support this podcast: https://anchor.fm/angularair/support

google front babel javascript angular typescript modern romance es6 nathan walker angular cli es5 alex eagle modern romance aziz ansari angular air jeff whelpley typescript deep dive angularclass

077 AiA 2016 Year Predictions

Play Episode Listen Later Jan 21, 2016 66:17

02:34 - Angular in 2015 Visual Studio Code 09:11 - Tooling 10:47 - Angular 2 Courses, Style Guide 13:01 - People Leaving Angular for React ?? 14:31 - No New Frameworks of Consequence in 2016 ?? Cycle.js Elm 21:50 - New Year’s Challenge: Communicate “Why” Pair Programming 25:12 - Opinionated Blog Posts and Rants 28:42 - Mobile Developers and Applications 33:44 - Angular 2 LIVE Predictions Lukas: June 15th John: May 4th (ng-conf) Chuck: mid-July Ward: August Joe: April 1st 39:54 - ES2015/6, ES7 41:15 - Bootstrap Takes a Backseat 41:48 - Inline Styles 43:43 - Containers 44:08 - NOSQL Databases 44:35 - Java 45:06 - Ruby 45:35 - PHP 46:34 - Bootcamps / Coding Camps Education and Job Attainability 54:02 - Revolt on ES6 => Go Back to ES5 ?? 55:49 - WebAssembly Picks Mad Max: Fury Road (Ward) Luca Sestak Duo - Key Engine (Lukas) Star Wars: The Force Awakens (Joe) littleBits (Joe) Submit a CFP for ng-conf! (Joe) Spending time with family (John) Clash of Clans (Chuck) All Remote Confs (Chuck) Swarm Simulator (Chuck) CES (Chuck) The Venetian Hotel (Chuck)

new year education consequences cycle spending clash ces ward react applications rants courses cfp pair java revolts takes mad max fury road star wars the force awakens php containers elm backseat bootstrap clans angular tooling readme style guides webassembly visual studio code pair programming littlebits year predictions es6 john may venetian hotel es5 es7 es2015 nosql databases mobile developers all remote confs

077 AiA 2016 Year Predictions

Play Episode Listen Later Jan 21, 2016 66:17

02:34 - Angular in 2015 Visual Studio Code 09:11 - Tooling 10:47 - Angular 2 Courses, Style Guide 13:01 - People Leaving Angular for React ?? 14:31 - No New Frameworks of Consequence in 2016 ?? Cycle.js Elm 21:50 - New Year’s Challenge: Communicate “Why” Pair Programming 25:12 - Opinionated Blog Posts and Rants 28:42 - Mobile Developers and Applications 33:44 - Angular 2 LIVE Predictions Lukas: June 15th John: May 4th (ng-conf) Chuck: mid-July Ward: August Joe: April 1st 39:54 - ES2015/6, ES7 41:15 - Bootstrap Takes a Backseat 41:48 - Inline Styles 43:43 - Containers 44:08 - NOSQL Databases 44:35 - Java 45:06 - Ruby 45:35 - PHP 46:34 - Bootcamps / Coding Camps Education and Job Attainability 54:02 - Revolt on ES6 => Go Back to ES5 ?? 55:49 - WebAssembly Picks Mad Max: Fury Road (Ward) Luca Sestak Duo - Key Engine (Lukas) Star Wars: The Force Awakens (Joe) littleBits (Joe) Submit a CFP for ng-conf! (Joe) Spending time with family (John) Clash of Clans (Chuck) All Remote Confs (Chuck) Swarm Simulator (Chuck) CES (Chuck) The Venetian Hotel (Chuck)

new year education consequences cycle spending clash ces ward react applications rants courses cfp pair java revolts takes mad max fury road star wars the force awakens php containers elm backseat bootstrap clans angular tooling readme style guides webassembly visual studio code pair programming littlebits year predictions es6 john may venetian hotel es5 es7 es2015 nosql databases mobile developers all remote confs

077 AiA 2016 Year Predictions

Play Episode Listen Later Jan 21, 2016 66:17

02:34 - Angular in 2015 Visual Studio Code 09:11 - Tooling 10:47 - Angular 2 Courses, Style Guide 13:01 - People Leaving Angular for React ?? 14:31 - No New Frameworks of Consequence in 2016 ?? Cycle.js Elm 21:50 - New Year’s Challenge: Communicate “Why” Pair Programming 25:12 - Opinionated Blog Posts and Rants 28:42 - Mobile Developers and Applications 33:44 - Angular 2 LIVE Predictions Lukas: June 15th John: May 4th (ng-conf) Chuck: mid-July Ward: August Joe: April 1st 39:54 - ES2015/6, ES7 41:15 - Bootstrap Takes a Backseat 41:48 - Inline Styles 43:43 - Containers 44:08 - NOSQL Databases 44:35 - Java 45:06 - Ruby 45:35 - PHP 46:34 - Bootcamps / Coding Camps Education and Job Attainability 54:02 - Revolt on ES6 => Go Back to ES5 ?? 55:49 - WebAssembly Picks Mad Max: Fury Road (Ward) Luca Sestak Duo - Key Engine (Lukas) Star Wars: The Force Awakens (Joe) littleBits (Joe) Submit a CFP for ng-conf! (Joe) Spending time with family (John) Clash of Clans (Chuck) All Remote Confs (Chuck) Swarm Simulator (Chuck) CES (Chuck) The Venetian Hotel (Chuck)

new year education consequences cycle spending clash ces ward react applications rants courses cfp pair java revolts takes mad max fury road star wars the force awakens php containers elm backseat bootstrap clans angular tooling readme style guides webassembly visual studio code pair programming littlebits year predictions es6 john may venetian hotel es5 es7 es2015 nosql databases mobile developers all remote confs

064 AiA Ionic with Matt Kremer and Mike Hartington

Play Episode Listen Later Oct 22, 2015 61:20

02:18 - Mike Hartington Introduction Twitter GitHub Blog 02:27 - Matt Kremer Introduction Twitter GitHub Blog 02:36 - The Ionic Framework and Ionic Creator Getting Started with Ionic 05:25 - ngCordova Apache Cordova 07:14 - Performance 10:29 - Cordova (Cont’d) 11:47 - Use Cases Sworkit 12:37 - Plugins ngCordova Plugins Overview 13:54 - What Ionic is NOT Ideal For 16:09 - Local Data Storage 17:27 - Fidelity of Interactions 20:54 - The Business Side of Ionic 23:13 - When should I go native? When should I go hybrid? Simon Reimler: Switching from native iOS to Ionic: Why Hybrid doesn't suck (anymore) Sharing Code 27:58 - Business Cases: Convincing Others to Use Ionic 32:44 - Tools for Apache Cordova (TACO) Overlap 36:34 - Deployment 38:58 - Ionic and Angular 2 John Papa’s Angular Style Guide Transitioning Your App from ES5 to TypeScript 45:06 - IDE Support Ionic Lab Electron Picks RAVPower 23000mAh Portable Charger Power Bank External Battery Pack (Joe) iZombie (Joe) Anglebrackets Conference (John) The Standing Athlete | Feat. Kelly Starrett | Ep. 274 | MobilityWOD (Lukas) Kelly Starrett’s Standing Desk Tips (Lukas) Charles Max Wood: Standing Desk and Upgrading My Health (Chuck) Thirsty Light Curve (Chuck) Beardr (Matt) Blab (Matt) Untappd (Mike)

performance tools blog ios getting started github interactions deployment use cases plugins angular overlap electron business side blab izombie typescript kremer ionic kelly starrett untappd mobilitywod john papa sworkit ionic framework es5 apache cordova mike hartington ionic creator angular style guide ngcordova

064 AiA Ionic with Matt Kremer and Mike Hartington

Play Episode Listen Later Oct 22, 2015 61:20

02:18 - Mike Hartington Introduction Twitter GitHub Blog 02:27 - Matt Kremer Introduction Twitter GitHub Blog 02:36 - The Ionic Framework and Ionic Creator Getting Started with Ionic 05:25 - ngCordova Apache Cordova 07:14 - Performance 10:29 - Cordova (Cont’d) 11:47 - Use Cases Sworkit 12:37 - Plugins ngCordova Plugins Overview 13:54 - What Ionic is NOT Ideal For 16:09 - Local Data Storage 17:27 - Fidelity of Interactions 20:54 - The Business Side of Ionic 23:13 - When should I go native? When should I go hybrid? Simon Reimler: Switching from native iOS to Ionic: Why Hybrid doesn't suck (anymore) Sharing Code 27:58 - Business Cases: Convincing Others to Use Ionic 32:44 - Tools for Apache Cordova (TACO) Overlap 36:34 - Deployment 38:58 - Ionic and Angular 2 John Papa’s Angular Style Guide Transitioning Your App from ES5 to TypeScript 45:06 - IDE Support Ionic Lab Electron Picks RAVPower 23000mAh Portable Charger Power Bank External Battery Pack (Joe) iZombie (Joe) Anglebrackets Conference (John) The Standing Athlete | Feat. Kelly Starrett | Ep. 274 | MobilityWOD (Lukas) Kelly Starrett’s Standing Desk Tips (Lukas) Charles Max Wood: Standing Desk and Upgrading My Health (Chuck) Thirsty Light Curve (Chuck) Beardr (Matt) Blab (Matt) Untappd (Mike)

performance tools blog ios getting started github interactions deployment use cases plugins angular overlap electron business side blab izombie typescript kremer ionic kelly starrett untappd mobilitywod john papa sworkit ionic framework es5 apache cordova mike hartington ionic creator angular style guide ngcordova

064 AiA Ionic with Matt Kremer and Mike Hartington

Play Episode Listen Later Oct 22, 2015 61:20

02:18 - Mike Hartington Introduction Twitter GitHub Blog 02:27 - Matt Kremer Introduction Twitter GitHub Blog 02:36 - The Ionic Framework and Ionic Creator Getting Started with Ionic 05:25 - ngCordova Apache Cordova 07:14 - Performance 10:29 - Cordova (Cont’d) 11:47 - Use Cases Sworkit 12:37 - Plugins ngCordova Plugins Overview 13:54 - What Ionic is NOT Ideal For 16:09 - Local Data Storage 17:27 - Fidelity of Interactions 20:54 - The Business Side of Ionic 23:13 - When should I go native? When should I go hybrid? Simon Reimler: Switching from native iOS to Ionic: Why Hybrid doesn't suck (anymore) Sharing Code 27:58 - Business Cases: Convincing Others to Use Ionic 32:44 - Tools for Apache Cordova (TACO) Overlap 36:34 - Deployment 38:58 - Ionic and Angular 2 John Papa’s Angular Style Guide Transitioning Your App from ES5 to TypeScript 45:06 - IDE Support Ionic Lab Electron Picks RAVPower 23000mAh Portable Charger Power Bank External Battery Pack (Joe) iZombie (Joe) Anglebrackets Conference (John) The Standing Athlete | Feat. Kelly Starrett | Ep. 274 | MobilityWOD (Lukas) Kelly Starrett’s Standing Desk Tips (Lukas) Charles Max Wood: Standing Desk and Upgrading My Health (Chuck) Thirsty Light Curve (Chuck) Beardr (Matt) Blab (Matt) Untappd (Mike)

performance tools blog ios getting started github interactions deployment use cases plugins angular overlap electron business side blab izombie typescript kremer ionic kelly starrett untappd mobilitywod john papa sworkit ionic framework es5 apache cordova mike hartington ionic creator angular style guide ngcordova

060 AiA Further Down the Road to NG2

Play Episode Listen Later Sep 17, 2015 46:28

This episode is a follow-up episode of Adventures in Angular Episode #48: The Road to NG2 Also, don’t forget to get your Angular Remote Conf Tickets! The online/completely remote conference will run from Thursday, September 24th thru Saturday, September 26th. 03:18 - Panelist Recent Experimentation 06:25 - ES6 vs Typescript, Tooling Dan Wahlin and John Papa Bringing Their View On The Latest In Angular @ Angular U 2015 Atom Visual Studio Code Webstorm Grunt / Gulp 11:21 - Destructuring Destructuring and parameter handling in ECMAScript 6 16:01 - Debugging 17:07 - Angular 1 => 2 MVC Key Features Needed Getting in the Front Door (Getting Past the Ecosystem) Angular 1 and Angular 2 integration: the path to seamless upgrade 27:32 - Angular 2 & ES5 Pascal Precht: Even better ES5 code for Angular 2 29:44 - Components, Annotations 32:45 - Editors: What Microsoft Users Are Doing TypeScript-Sublime-Plugin atom-typescript 38:35 - Learning Lessons (From Panelists) Picks Angular Articles by Pascal Precht (Lukas) Enter the ng-conf ticket lottery (Joe)

adventures tickets ecosystem components atom angular down the road grunt gulp typescript mvc tooling debugging annotations visual studio code es6 ecmascript webstorm es5 ng2 dan wahlin model e2 destructuring angular remote conf pascal precht videosession angular episode angular articles

060 AiA Further Down the Road to NG2

Play Episode Listen Later Sep 17, 2015 46:28

This episode is a follow-up episode of Adventures in Angular Episode #48: The Road to NG2 Also, don’t forget to get your Angular Remote Conf Tickets! The online/completely remote conference will run from Thursday, September 24th thru Saturday, September 26th. 03:18 - Panelist Recent Experimentation 06:25 - ES6 vs Typescript, Tooling Dan Wahlin and John Papa Bringing Their View On The Latest In Angular @ Angular U 2015 Atom Visual Studio Code Webstorm Grunt / Gulp 11:21 - Destructuring Destructuring and parameter handling in ECMAScript 6 16:01 - Debugging 17:07 - Angular 1 => 2 MVC Key Features Needed Getting in the Front Door (Getting Past the Ecosystem) Angular 1 and Angular 2 integration: the path to seamless upgrade 27:32 - Angular 2 & ES5 Pascal Precht: Even better ES5 code for Angular 2 29:44 - Components, Annotations 32:45 - Editors: What Microsoft Users Are Doing TypeScript-Sublime-Plugin atom-typescript 38:35 - Learning Lessons (From Panelists) Picks Angular Articles by Pascal Precht (Lukas) Enter the ng-conf ticket lottery (Joe)

adventures tickets ecosystem components atom angular down the road grunt gulp typescript mvc tooling debugging annotations visual studio code es6 ecmascript webstorm es5 ng2 dan wahlin model e2 destructuring angular remote conf pascal precht videosession angular episode angular articles

060 AiA Further Down the Road to NG2

Play Episode Listen Later Sep 17, 2015 46:28

This episode is a follow-up episode of Adventures in Angular Episode #48: The Road to NG2 Also, don’t forget to get your Angular Remote Conf Tickets! The online/completely remote conference will run from Thursday, September 24th thru Saturday, September 26th. 03:18 - Panelist Recent Experimentation 06:25 - ES6 vs Typescript, Tooling Dan Wahlin and John Papa Bringing Their View On The Latest In Angular @ Angular U 2015 Atom Visual Studio Code Webstorm Grunt / Gulp 11:21 - Destructuring Destructuring and parameter handling in ECMAScript 6 16:01 - Debugging 17:07 - Angular 1 => 2 MVC Key Features Needed Getting in the Front Door (Getting Past the Ecosystem) Angular 1 and Angular 2 integration: the path to seamless upgrade 27:32 - Angular 2 & ES5 Pascal Precht: Even better ES5 code for Angular 2 29:44 - Components, Annotations 32:45 - Editors: What Microsoft Users Are Doing TypeScript-Sublime-Plugin atom-typescript 38:35 - Learning Lessons (From Panelists) Picks Angular Articles by Pascal Precht (Lukas) Enter the ng-conf ticket lottery (Joe)

adventures tickets ecosystem components atom angular down the road grunt gulp typescript mvc tooling debugging annotations visual studio code es6 ecmascript webstorm es5 ng2 dan wahlin model e2 destructuring angular remote conf pascal precht videosession angular episode angular articles

048 AiA The Road to NG2

Play Episode Listen Later Jun 25, 2015 49:04

03:51 - Dilemma of Choice: Onboarding Process AngularJS Homepage Angular 2: 5 Minute Quickstart Friction Dan Wahlin: AngularJS in 20ish Minutes 12:45 - Frameworks => Structured Languages Are we leaving behind the casual web developer? 17:47 - Do Angular 1 with TypeScript, etc., before doing it with Angular 2 Scott Moss PatrickJS 20:46 - ES5 with Angular 2 23:45 - Wrangling Tools Source Code > Documentation TodoService in Angular 2 and Angular 1 both in TypeScript and ES5 systemjs 28:58 - If you’re starting an app now…what do you do? Adventures in Angular Episode #020: Structuring Code in an AngularJS App with Dan Wahlin Adventures in Angular Episode #039: ES6 with Scott Moss Explaining Value 39:36 - Applying Concepts 42:12 - Repos github.com/johnpapa hottowel-angular-typescript ng2play Picks The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim (Lukas) Arrow (John) Ex Machina (Ward) Listen to other people’s views (Chuck)

adventures dilemma ward arrow friction devops frameworks documentation ex machina angular source code typescript repos gene kim es6 helping your business win scott moss es5 dan wahlin angular episode tnxo i7944m structuring code angularjs app creativeasin b00azrblho todoservice

048 AiA The Road to NG2

Play Episode Listen Later Jun 25, 2015 49:04

03:51 - Dilemma of Choice: Onboarding Process AngularJS Homepage Angular 2: 5 Minute Quickstart Friction Dan Wahlin: AngularJS in 20ish Minutes 12:45 - Frameworks => Structured Languages Are we leaving behind the casual web developer? 17:47 - Do Angular 1 with TypeScript, etc., before doing it with Angular 2 Scott Moss PatrickJS 20:46 - ES5 with Angular 2 23:45 - Wrangling Tools Source Code > Documentation TodoService in Angular 2 and Angular 1 both in TypeScript and ES5 systemjs 28:58 - If you’re starting an app now…what do you do? Adventures in Angular Episode #020: Structuring Code in an AngularJS App with Dan Wahlin Adventures in Angular Episode #039: ES6 with Scott Moss Explaining Value 39:36 - Applying Concepts 42:12 - Repos github.com/johnpapa hottowel-angular-typescript ng2play Picks The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim (Lukas) Arrow (John) Ex Machina (Ward) Listen to other people’s views (Chuck)

adventures dilemma ward arrow friction devops frameworks documentation ex machina angular source code typescript repos gene kim es6 helping your business win scott moss es5 dan wahlin angular episode tnxo i7944m structuring code angularjs app creativeasin b00azrblho todoservice

048 AiA The Road to NG2

Play Episode Listen Later Jun 25, 2015 49:04

03:51 - Dilemma of Choice: Onboarding Process AngularJS Homepage Angular 2: 5 Minute Quickstart Friction Dan Wahlin: AngularJS in 20ish Minutes 12:45 - Frameworks => Structured Languages Are we leaving behind the casual web developer? 17:47 - Do Angular 1 with TypeScript, etc., before doing it with Angular 2 Scott Moss PatrickJS 20:46 - ES5 with Angular 2 23:45 - Wrangling Tools Source Code > Documentation TodoService in Angular 2 and Angular 1 both in TypeScript and ES5 systemjs 28:58 - If you’re starting an app now…what do you do? Adventures in Angular Episode #020: Structuring Code in an AngularJS App with Dan Wahlin Adventures in Angular Episode #039: ES6 with Scott Moss Explaining Value 39:36 - Applying Concepts 42:12 - Repos github.com/johnpapa hottowel-angular-typescript ng2play Picks The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim (Lukas) Arrow (John) Ex Machina (Ward) Listen to other people’s views (Chuck)

adventures dilemma ward arrow friction devops frameworks documentation ex machina angular source code typescript repos gene kim es6 helping your business win scott moss es5 dan wahlin angular episode tnxo i7944m structuring code angularjs app creativeasin b00azrblho todoservice

047 AiA Angular 1 to Angular 2 with Patrick Stapleton

Play Episode Listen Later Jun 18, 2015 44:43

02:32 - Patrick Stapleton Introduction Twitter GitHub Blog Angular Class @AngularClass Keychain Logistics @Keychain Hack Reactor @HackReactor Reddit Insight 04:21 - Angular 2 and Where It’s Headed 05:04 - Enterprise/Small App Distinction 07:19 - Angular 2 Preparation and Migration TodoService in Angular 2 and Angular 1 both in TypeScript and ES5 Babel TypeScript 10:35 - Authoring Scenario in ES5 vs ES6 13:44 - Composition Over Inheritance The Class System Duck Typing 18:47 - Services and Directives Patrick Stapleton and Aysegul Yonet: Creating d3 components with Angular2 and TypeScript @ ng-vegas 2015 20:48 - Controller vs Link Function 22:21 - The Router 24:21 - Two-way Data Binding ngModel Template-Driven, Data-Driven Picks Amarda: A Novel by Ernest Cline (Aaron) (Chapter 1) Take A First Look At Ernest Cline's Armada (Aaron) Angular Summit (Aaron) Sign Language (Katya) Luther Ingram - If Loving You Is Wrong (Ward) AngularU (Ward) Thinking, Fast and Slow by Daniel Kahneman (Ward) Denmark (Joe) Angular 2 (Patrick) Babel (Patrick)

thinking blog services preparation denmark ward duck migration headed babel github data driven controller armada daniel kahneman creativeasin angular router sign language ernest cline typescript directives keychain es6 class system hack reactor es5 data binding angular2 duck typing link function angular u patrick stapleton ngmodel angular summit angularclass x296y5merwi aysegul yonet creating patrick stapleton introduction todoservice

047 AiA Angular 1 to Angular 2 with Patrick Stapleton

Play Episode Listen Later Jun 18, 2015 44:43

02:32 - Patrick Stapleton Introduction Twitter GitHub Blog Angular Class @AngularClass Keychain Logistics @Keychain Hack Reactor @HackReactor Reddit Insight 04:21 - Angular 2 and Where It’s Headed 05:04 - Enterprise/Small App Distinction 07:19 - Angular 2 Preparation and Migration TodoService in Angular 2 and Angular 1 both in TypeScript and ES5 Babel TypeScript 10:35 - Authoring Scenario in ES5 vs ES6 13:44 - Composition Over Inheritance The Class System Duck Typing 18:47 - Services and Directives Patrick Stapleton and Aysegul Yonet: Creating d3 components with Angular2 and TypeScript @ ng-vegas 2015 20:48 - Controller vs Link Function 22:21 - The Router 24:21 - Two-way Data Binding ngModel Template-Driven, Data-Driven Picks Amarda: A Novel by Ernest Cline (Aaron) (Chapter 1) Take A First Look At Ernest Cline's Armada (Aaron) Angular Summit (Aaron) Sign Language (Katya) Luther Ingram - If Loving You Is Wrong (Ward) AngularU (Ward) Thinking, Fast and Slow by Daniel Kahneman (Ward) Denmark (Joe) Angular 2 (Patrick) Babel (Patrick)

thinking blog services preparation denmark ward duck migration headed babel github data driven controller armada daniel kahneman creativeasin angular router sign language ernest cline typescript directives keychain es6 class system hack reactor es5 data binding angular2 duck typing link function angular u patrick stapleton ngmodel angular summit angularclass x296y5merwi aysegul yonet creating patrick stapleton introduction todoservice

047 AiA Angular 1 to Angular 2 with Patrick Stapleton

Play Episode Listen Later Jun 18, 2015 44:43

02:32 - Patrick Stapleton Introduction Twitter GitHub Blog Angular Class @AngularClass Keychain Logistics @Keychain Hack Reactor @HackReactor Reddit Insight 04:21 - Angular 2 and Where It’s Headed 05:04 - Enterprise/Small App Distinction 07:19 - Angular 2 Preparation and Migration TodoService in Angular 2 and Angular 1 both in TypeScript and ES5 Babel TypeScript 10:35 - Authoring Scenario in ES5 vs ES6 13:44 - Composition Over Inheritance The Class System Duck Typing 18:47 - Services and Directives Patrick Stapleton and Aysegul Yonet: Creating d3 components with Angular2 and TypeScript @ ng-vegas 2015 20:48 - Controller vs Link Function 22:21 - The Router 24:21 - Two-way Data Binding ngModel Template-Driven, Data-Driven Picks Amarda: A Novel by Ernest Cline (Aaron) (Chapter 1) Take A First Look At Ernest Cline's Armada (Aaron) Angular Summit (Aaron) Sign Language (Katya) Luther Ingram - If Loving You Is Wrong (Ward) AngularU (Ward) Thinking, Fast and Slow by Daniel Kahneman (Ward) Denmark (Joe) Angular 2 (Patrick) Babel (Patrick)

thinking blog services preparation denmark ward duck migration headed babel github data driven controller armada daniel kahneman creativeasin angular router sign language ernest cline typescript directives keychain es6 class system hack reactor es5 data binding angular2 duck typing link function angular u patrick stapleton ngmodel angular summit angularclass x296y5merwi aysegul yonet creating patrick stapleton introduction todoservice

041 AiA TypeScript with Dan Wahlin

Play Episode Listen Later May 7, 2015 48:35

01:46 - Dan Wahlin Introduction Twitter GitHub Blog The Wahlin Group Pluralsight Author Page 02:29 - Background and Involvement in the Angular Community [YouTube] Dan Wahlin: AngularJS in 20ish Minutes (ng-conf 2014) [YouTube] TypeScript and ES6 Dan Wahlin & Andrew Connell (ng-conf2015) 04:16 - TypeScript TypeScript Source Code 06:02 - Why Care About TypeScript? 07:20 - ES3, ES5, ES6 10:00 - Type Support 11:41 - Refactoring 12:39 - Microsoft Involvement Open Source Source Open (Pull Request Acceptance) 17:45 - Benefits and Concerns .d.ts tslint 20:07 - TypeScript and Angular Directives and Providers Services vs Factories Functional Programming 24:11 - TypeScript and Angular 2 Angular.io 25:28 - Collaboration (AtScript => TypeScript) Annotations and Naming Conventions 30:47 - The Angular Community and TypeScript Tooling and Transpiling Babel traceur WebStorm 36:38 - Type Inference ng-flow Picks Avengers: Age of Ultron (John) Star Wars: Episode VII - The Force Awakens (John) .d.ts (John) Lord of the Rings (Katya) Avengers: Age of Ultron (Katya) Matterhorn: A Novel of the Vietnam War by Karl Marlantes (Aaron) Tyler Russell: An Angular2 Timezone Picker - Part 1: Becoming a Kartograph-er (Aaron) Tyler Russell: An Angular2 Timezone Picker - Part 2: Exploring the World (of Ng2) (Aaron) [Pluralsight] TypeScript Fundamentals by John Papa and Dan Wahlin (Lukas) DefinitelyTyped (Ward) Kent Meyers: The Quietest Place in the Universe: Digging For Dark Matter in An Abandoned Mine (Ward) Daredevil (Joe) GoFundMe (Joe) [GoFundMe] Send Samantha to Miss Amazing! (Joe) Headspace (Dan) Faker.js (Dan)

world lord benefits microsoft blog services concerns exploring lord of the rings rings ward gofundme babel functional vietnam war daredevil open source github involvement headspace ultron providers avengers age factories creativeasin angular typescript tooling directives faker refactoring annotations star wars episode vii the force awakens functional programming es6 naming conventions john papa karl marlantes webstorm abandoned mine es5 miss amazing ng2 wimovie andrew connell dan wahlin type inference es3 angular community transpiling matterhorn a novel definitelytyped microsoft typescript tnxo i7944m 20files dan wahlin introduction

041 AiA TypeScript with Dan Wahlin

Play Episode Listen Later May 7, 2015 48:35

01:46 - Dan Wahlin Introduction Twitter GitHub Blog The Wahlin Group Pluralsight Author Page 02:29 - Background and Involvement in the Angular Community [YouTube] Dan Wahlin: AngularJS in 20ish Minutes (ng-conf 2014) [YouTube] TypeScript and ES6 Dan Wahlin & Andrew Connell (ng-conf2015) 04:16 - TypeScript TypeScript Source Code 06:02 - Why Care About TypeScript? 07:20 - ES3, ES5, ES6 10:00 - Type Support 11:41 - Refactoring 12:39 - Microsoft Involvement Open Source Source Open (Pull Request Acceptance) 17:45 - Benefits and Concerns .d.ts tslint 20:07 - TypeScript and Angular Directives and Providers Services vs Factories Functional Programming 24:11 - TypeScript and Angular 2 Angular.io 25:28 - Collaboration (AtScript => TypeScript) Annotations and Naming Conventions 30:47 - The Angular Community and TypeScript Tooling and Transpiling Babel traceur WebStorm 36:38 - Type Inference ng-flow Picks Avengers: Age of Ultron (John) Star Wars: Episode VII - The Force Awakens (John) .d.ts (John) Lord of the Rings (Katya) Avengers: Age of Ultron (Katya) Matterhorn: A Novel of the Vietnam War by Karl Marlantes (Aaron) Tyler Russell: An Angular2 Timezone Picker - Part 1: Becoming a Kartograph-er (Aaron) Tyler Russell: An Angular2 Timezone Picker - Part 2: Exploring the World (of Ng2) (Aaron) [Pluralsight] TypeScript Fundamentals by John Papa and Dan Wahlin (Lukas) DefinitelyTyped (Ward) Kent Meyers: The Quietest Place in the Universe: Digging For Dark Matter in An Abandoned Mine (Ward) Daredevil (Joe) GoFundMe (Joe) [GoFundMe] Send Samantha to Miss Amazing! (Joe) Headspace (Dan) Faker.js (Dan)

world lord benefits microsoft blog services concerns exploring lord of the rings rings ward gofundme babel functional vietnam war daredevil open source github involvement headspace ultron providers avengers age factories creativeasin angular typescript tooling directives faker refactoring annotations star wars episode vii the force awakens functional programming es6 naming conventions john papa karl marlantes webstorm abandoned mine es5 miss amazing ng2 wimovie andrew connell dan wahlin type inference es3 angular community transpiling matterhorn a novel definitelytyped microsoft typescript tnxo i7944m 20files dan wahlin introduction

041 AiA TypeScript with Dan Wahlin

Play Episode Listen Later May 7, 2015 48:35

01:46 - Dan Wahlin Introduction Twitter GitHub Blog The Wahlin Group Pluralsight Author Page 02:29 - Background and Involvement in the Angular Community [YouTube] Dan Wahlin: AngularJS in 20ish Minutes (ng-conf 2014) [YouTube] TypeScript and ES6 Dan Wahlin & Andrew Connell (ng-conf2015) 04:16 - TypeScript TypeScript Source Code 06:02 - Why Care About TypeScript? 07:20 - ES3, ES5, ES6 10:00 - Type Support 11:41 - Refactoring 12:39 - Microsoft Involvement Open Source Source Open (Pull Request Acceptance) 17:45 - Benefits and Concerns .d.ts tslint 20:07 - TypeScript and Angular Directives and Providers Services vs Factories Functional Programming 24:11 - TypeScript and Angular 2 Angular.io 25:28 - Collaboration (AtScript => TypeScript) Annotations and Naming Conventions 30:47 - The Angular Community and TypeScript Tooling and Transpiling Babel traceur WebStorm 36:38 - Type Inference ng-flow Picks Avengers: Age of Ultron (John) Star Wars: Episode VII - The Force Awakens (John) .d.ts (John) Lord of the Rings (Katya) Avengers: Age of Ultron (Katya) Matterhorn: A Novel of the Vietnam War by Karl Marlantes (Aaron) Tyler Russell: An Angular2 Timezone Picker - Part 1: Becoming a Kartograph-er (Aaron) Tyler Russell: An Angular2 Timezone Picker - Part 2: Exploring the World (of Ng2) (Aaron) [Pluralsight] TypeScript Fundamentals by John Papa and Dan Wahlin (Lukas) DefinitelyTyped (Ward) Kent Meyers: The Quietest Place in the Universe: Digging For Dark Matter in An Abandoned Mine (Ward) Daredevil (Joe) GoFundMe (Joe) [GoFundMe] Send Samantha to Miss Amazing! (Joe) Headspace (Dan) Faker.js (Dan)

world lord benefits microsoft blog services concerns exploring lord of the rings rings ward gofundme babel functional vietnam war daredevil open source github involvement headspace ultron providers avengers age factories creativeasin angular typescript tooling directives faker refactoring annotations star wars episode vii the force awakens functional programming es6 naming conventions john papa karl marlantes webstorm abandoned mine es5 miss amazing ng2 wimovie andrew connell dan wahlin type inference es3 angular community transpiling matterhorn a novel definitelytyped microsoft typescript tnxo i7944m 20files dan wahlin introduction

039 AiA ES6 with Scott Moss

Play Episode Listen Later Apr 23, 2015 52:03

00:43 - Scott Moss Introduction Twitter GitHub Udacity @udacity Hack Reactor Angular Class @angularclass 01:55 - Scott’s Programming Background 04:11 - Working with Lukas 05:04 - Angular and ES6 (ECMAScript) John Papa's Angular Style Guide 06:11 - Subclassing a Directive Classical Inheritance DDO (Directive Definition Object) 08:58 - TypeScript Transpiling traceur-compiler babel Differences and Definitions: traceur, babel, TypeScript Learn about TypeScript 1.5 here and get it here [Pluralsight] John Papa and Dan Wahlin: TypeScript Fundamentals Types Have Value 19:06 - How should people use a transpiler in a real application? webpack gulp.js jspm 21:07 - systemjs 21:53 - Build Systems vs Package Managers 24:15 - Writing Tests in ES6 26:03 - Debugging 28:20 - How coding in ES6 has changed Scott’s style of building Angular 1 apps 30:19 - Modularity Arrow Functions 33:07 - ES5 with Angular 2?? 37:31 - Good Example of Using ES6 with Angular GoCardless GoCardless Angular Style Guide 39:21 - Learning New Material and Using ES6 Picks Learn about TypeScript 1.5 (Ward) The Effective Engineer by Edmond Lau (Lukas) Isar Raw Canvas Backpack (Lukas) INcontroL (Joe) John’s Daughter (John) Angular U (John) The Imitation Game (Katya) Treeline (Scott) Interstellar (Scott)

differences ward interstellar github definitions directive angular imitation game typescript debugging in control udacity good example modularity gocardless es6 ecmascript build systems treeline john papa hack reactor scott moss es5 writing tests edmond lau arrow functions transpiling using es6 angular u subclassing angular style guide angularclass

039 AiA ES6 with Scott Moss

Play Episode Listen Later Apr 23, 2015 52:03

00:43 - Scott Moss Introduction Twitter GitHub Udacity @udacity Hack Reactor Angular Class @angularclass 01:55 - Scott’s Programming Background 04:11 - Working with Lukas 05:04 - Angular and ES6 (ECMAScript) John Papa's Angular Style Guide 06:11 - Subclassing a Directive Classical Inheritance DDO (Directive Definition Object) 08:58 - TypeScript Transpiling traceur-compiler babel Differences and Definitions: traceur, babel, TypeScript Learn about TypeScript 1.5 here and get it here [Pluralsight] John Papa and Dan Wahlin: TypeScript Fundamentals Types Have Value 19:06 - How should people use a transpiler in a real application? webpack gulp.js jspm 21:07 - systemjs 21:53 - Build Systems vs Package Managers 24:15 - Writing Tests in ES6 26:03 - Debugging 28:20 - How coding in ES6 has changed Scott’s style of building Angular 1 apps 30:19 - Modularity Arrow Functions 33:07 - ES5 with Angular 2?? 37:31 - Good Example of Using ES6 with Angular GoCardless GoCardless Angular Style Guide 39:21 - Learning New Material and Using ES6 Picks Learn about TypeScript 1.5 (Ward) The Effective Engineer by Edmond Lau (Lukas) Isar Raw Canvas Backpack (Lukas) INcontroL (Joe) John’s Daughter (John) Angular U (John) The Imitation Game (Katya) Treeline (Scott) Interstellar (Scott)

differences ward interstellar github definitions directive angular imitation game typescript debugging in control udacity good example modularity gocardless es6 ecmascript build systems treeline john papa hack reactor scott moss es5 writing tests edmond lau arrow functions transpiling using es6 angular u subclassing angular style guide angularclass

039 AiA ES6 with Scott Moss

Play Episode Listen Later Apr 23, 2015 52:03

00:43 - Scott Moss Introduction Twitter GitHub Udacity @udacity Hack Reactor Angular Class @angularclass 01:55 - Scott’s Programming Background 04:11 - Working with Lukas 05:04 - Angular and ES6 (ECMAScript) John Papa's Angular Style Guide 06:11 - Subclassing a Directive Classical Inheritance DDO (Directive Definition Object) 08:58 - TypeScript Transpiling traceur-compiler babel Differences and Definitions: traceur, babel, TypeScript Learn about TypeScript 1.5 here and get it here [Pluralsight] John Papa and Dan Wahlin: TypeScript Fundamentals Types Have Value 19:06 - How should people use a transpiler in a real application? webpack gulp.js jspm 21:07 - systemjs 21:53 - Build Systems vs Package Managers 24:15 - Writing Tests in ES6 26:03 - Debugging 28:20 - How coding in ES6 has changed Scott’s style of building Angular 1 apps 30:19 - Modularity Arrow Functions 33:07 - ES5 with Angular 2?? 37:31 - Good Example of Using ES6 with Angular GoCardless GoCardless Angular Style Guide 39:21 - Learning New Material and Using ES6 Picks Learn about TypeScript 1.5 (Ward) The Effective Engineer by Edmond Lau (Lukas) Isar Raw Canvas Backpack (Lukas) INcontroL (Joe) John’s Daughter (John) Angular U (John) The Imitation Game (Katya) Treeline (Scott) Interstellar (Scott)

differences ward interstellar github definitions directive angular imitation game typescript debugging in control udacity good example modularity gocardless es6 ecmascript build systems treeline john papa hack reactor scott moss es5 writing tests edmond lau arrow functions transpiling using es6 angular u subclassing angular style guide angularclass

038 AiA Performance with Ben Nadel

Play Episode Listen Later Apr 16, 2015 56:32

01:35 - Katya Eames Introduction Twitter [YouTube] Katya Eames: How to Teach Angular to Your Kids 01:52 - Ben Nadel Introduction Twitter GitHub Blog Adventures in Angular Episode 029: Angular At Work with Ben Nadel InVision @InVisionApp 04:47 - Performance Basecamp Nested Pages 08:04 - User Experience 10:01 - Fixing Performance Problems as a Team Engineering Validation “Premature optimization is the root of all evil -- Donald Knuth” DOM Manipulation ngRepeat Screen Experience 23:28 - Finding Performance Issues Chrome Developer Tools Firefox Firebug Utilizing Chrome Dev Tools and Creating the Videos on Ben’s Blog “Imposter Syndrome” Addy Osmani Paul Irish 29:27 - “Just-in-Time View Construction” 34:43 - ngIf 37:16 - Angular 2 Opinions [YouTube] Dave Smith: Angular + React = Speed Unit Directional Data Flow & Functionality Victor Savkin: Change Detection in Angular 2 [Egghead.io] John Lindquist: Angular 2: Template Syntax ES5, ES6 AtScript, TypeScript traceur-compiler Babel 46:01 - Moving to 2.0 Picks BrowserSync (John) [Egghead.io] Angular 2: Template Syntax (Joe) Win an InVision App T-Shirt! (Lukas) Adventures in Angular (Lukas) WELCOME TO NIGHT VALE (Katya) Being and Time (Harper Perennial Modern Thought) by Martin Heidegger (Ward) Angular Grid (Ward) Steelheart (The Reckoners) by Brandon Sanderson (Chuck) StarTech.com MUHSMF2M 2m 4 Position TRRS Headset Extension Cable (Ben) Any Given Sunday (Ben) News ng-vegas: May 7th and 8th, 2015! AngularU in the Bay Area in June

moving news performance team blog adventures videos imposter syndrome bay area ward utilizing babel impostors t shirts github user experience basecamp firefox premature creativeasin brandon sanderson angular your kids functionality typescript any given sunday martin heidegger invision eggheads firebug welcome to night vale es6 donald knuth chrome devtools paul irish startech addy osmani es5 invisionapp change detection ben nadel chrome developer tools steelheart the reckoners dom manipulation angular episode angular u browsersync atscript ngif xqm0k6yg18s koshkaeames ah9plt77cjm teach angular savkin ben nadel introduction angular at work unit directional data flow ngrepeat

038 AiA Performance with Ben Nadel

Play Episode Listen Later Apr 16, 2015 56:32

01:35 - Katya Eames Introduction Twitter [YouTube] Katya Eames: How to Teach Angular to Your Kids 01:52 - Ben Nadel Introduction Twitter GitHub Blog Adventures in Angular Episode 029: Angular At Work with Ben Nadel InVision @InVisionApp 04:47 - Performance Basecamp Nested Pages 08:04 - User Experience 10:01 - Fixing Performance Problems as a Team Engineering Validation “Premature optimization is the root of all evil -- Donald Knuth” DOM Manipulation ngRepeat Screen Experience 23:28 - Finding Performance Issues Chrome Developer Tools Firefox Firebug Utilizing Chrome Dev Tools and Creating the Videos on Ben’s Blog “Imposter Syndrome” Addy Osmani Paul Irish 29:27 - “Just-in-Time View Construction” 34:43 - ngIf 37:16 - Angular 2 Opinions [YouTube] Dave Smith: Angular + React = Speed Unit Directional Data Flow & Functionality Victor Savkin: Change Detection in Angular 2 [Egghead.io] John Lindquist: Angular 2: Template Syntax ES5, ES6 AtScript, TypeScript traceur-compiler Babel 46:01 - Moving to 2.0 Picks BrowserSync (John) [Egghead.io] Angular 2: Template Syntax (Joe) Win an InVision App T-Shirt! (Lukas) Adventures in Angular (Lukas) WELCOME TO NIGHT VALE (Katya) Being and Time (Harper Perennial Modern Thought) by Martin Heidegger (Ward) Angular Grid (Ward) Steelheart (The Reckoners) by Brandon Sanderson (Chuck) StarTech.com MUHSMF2M 2m 4 Position TRRS Headset Extension Cable (Ben) Any Given Sunday (Ben) News ng-vegas: May 7th and 8th, 2015! AngularU in the Bay Area in June

moving news performance team blog adventures videos imposter syndrome bay area ward utilizing babel impostors t shirts github user experience basecamp firefox premature creativeasin brandon sanderson angular your kids functionality typescript any given sunday martin heidegger invision eggheads firebug welcome to night vale es6 donald knuth chrome devtools paul irish startech addy osmani es5 invisionapp change detection ben nadel chrome developer tools steelheart the reckoners dom manipulation angular episode angular u browsersync atscript ngif xqm0k6yg18s koshkaeames ah9plt77cjm teach angular savkin ben nadel introduction angular at work unit directional data flow ngrepeat

038 AiA Performance with Ben Nadel