Modern JavaScript Testing: Integration, Contract Testing & AI Tools - JSJ 692

In this episode of JavaScript Jabber, Charles talks about the new direction he has for the company. He wants  to drive people to the point that they have the skills that make people want to hire and work with them, to teach them how to ‘Max out’. Today the panel the skills that developers need to progress in their careers: social skills. The panel talks about their observations from work that the people who advanced and grow in their career were the ones with social skills, not necessarily with technical skills. The company wants to get stuff done, and if your social skills are getting in the way of projects getting done because you can’t work with others, you are not that useful to the company, and you will be stuck in the lower ranks while others who may not have the same technical skills will rise in the ranks because they are pleasant to work with. Mani talks about his personal experience getting laid off for lacking these soft skills. But then he read the book 48 Laws of Power by Robert Green, realized his shortcomings, and started to apply just one lesson from the book. Within 6 months, he was promoted.Mani delves deeper into the first lesson taught in 48 Laws of Power, Never Outshine the Master. Fundamentally, this means that you don’t try to prove in meetings how good you are, or that they’re wrong, or that you think that you are better than them. The more you the aforementioned things, the less likely you will be to get promoted or trusted. Mani talks about how he used to do these things and how it cost him multiple jobs. When he put this lesson into practice, he changed his methods and the boss started to like him, leading to his promotion 6 months later. The panel discusses this lesson and what benefits can come from it. Mani shares another lesson that he learned through the story of a friend trying to get him to invest in his business. After Mani refused to invest multiple times, his friend stopped asking him to invest, but instead asked him for business advice. Eventually, Mani invested in the business because when he saw that his friend was influenced by his advice, it engendered trust between them. The panel agrees that if you want to influence someone, you have to be influenced by them. It is important to treat someone as a person rather than an asset or wallet, and ensure them that their investment is not their end goal. One of the most fundamental social skills that you must be able to like people, because other people can smell manipulation. The panel transitions to talking about the paradoxical nature of social skills and that they are often the opposite of what you think will work in a situation. Unfortunately, there will always be difficult people to work with. To illustrate how to work with difficult people, Mani shares the story of how Gengis Khan was convinced not to destroy a city of artists and engineers by his advisor, Yelu Chucai. Gengis Khan agreed because Yelu Chucai was able to structure his plea in a way that would also benefit Gengis Khan. The conversation shifts to how to conduct an interview to see if a candidate will fit into your team culture. First, you must know what you’re looking for and understand your team culture, and then ask for stories of when they accomplished something in the interview. If every story is all about how they did something and they don’t include other people, then that may indicate their self-centeredness. They discuss the Ben Franklin Effect. For those listeners wondering where to begin with all this self improvement, Mani has read over 2,000 books on business and offers a course on his website, 2000books.com. Mani has teamed up with JavaScript Jabber to offer a special deal to the listeners of this podcast. To get lifetime access to Mani’s courses at a 40% discount, follow the links below. PanelistsSteve EdwardsCharles Max WoodWith special guest: Mani VayaSponsorsReact Native RadioSentry use the code “devchat” for 2 months free on Sentry’s small plan React Round UpLinks48 Laws of Power by Robert Green The 360 Degree Leader by John C. Maxwell The Ben Franklin Effectjavascriptjabber.com/social and 2000books.com 40% off for the first 200 peopleCoupon code: Jabber Follow DevChatTV on Facebook and Twitter PicksSteve Edwards:Rex ChapmanCharles Max Wood:BombBombIndieHackers.com  Stolen bike prankMani Vaya: How I Built This by NPRAs a Man ThinkethSpecial Guest: Mani Vaya. Support this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

24 Okt 20191h 9min

Vitali Zaidman is a full stack developer who works for WellDone Software Solutions and is currently working on a SEO project. Today’s show is about SEO for developers. SEO stands for search engine optimization, which helps your website appear higher on search engines. SEO has changed a lot in the past 10 years. It has become much more regulated, and the “dirty tricks” of the past will actually penalize you, so it is important to do it properly. Today the best way to promote yourself on Google besides making good content is for developers to optimize the content, make it small, operational, secure, accessible, and operate on mobile. Much of it goes back to using semantic HTML since Google looks at it before looking at the structure of your website, how valuable it is, and how users interact with it. Having good semantics helps Google determine how valuable it is, so semantic HTML should be a top priority. Semantic HTML can also make your site more accessible to users, which will in turn give you a larger audience. The panel talks about some of the challenges of SEO faced by companies. While bigger companies have the privilege of dedicated SEO teams, small companies often lack these specialists. Thankfully, Google has made their guidelines for SEO very accessible and gives you a lot of tools to track your optimization. The panel talks about different methods of SEO, such as including FAQ at the bottom of the web page, optimizing page speed, and image optimization. Structured data like questions and answers enriches the data that is shown for users on the search results page. To score your website’s SEO, Google released the tool PageSpeed Insights, which will assign your website a performance score. Google uses two main tools to track a website’s SEO. First, they use real field data. If you opt in to ‘help improve Chrome’s features and performance’ when you install Chrome, it tracks how fast websites load on your Chrome, and they collect this information to understand how webpages load. It is required that your website has a certain amount of visitors to be tracked and added to the database. Second, Google has their own devices that will check your website. Currently, they are using a Moto G4 to test for mobile access, and a slow internet connection. Because of this, it is pretty easy to get a good score on desktop, but difficult to get a good score on mobile. The technology that drives all this is called Lighthouse. Overall, performance is the main thing users look for, so aim for good performance and fast websites. The panel discusses the correlation between performance and SEO. For example, Fox News and CNN are two of the top search results for ‘news’, but they have a dismal Google PSI score. They conclude that performance shouldn’t be ignored, but be careful about directly correlating performance and SEO. They also caution against getting obsessed over certain aspects of SEO by themselves. PanelistsDan ShapirAimee KnightCharles Max WoodWith special guest: Vitali ZaidmanSponsorsTideliftSentry use the code “devchat” for 2 months free on Sentry’s small plan Elixir MixLinksSEOJSONGoogle Webmaster guidelinesGoogle PageSpeed InsightsChrome CrUXLighthouseHere's How the Google Speed Update Will Impact Your SiteSEO for Developers - A Quick OverviewGoogle Quality Guidelines Follow DevChatTV on Facebook and Twitter PicksAimee Knight:Spotify CLIDan Shapir:Chrome Dev Summit 2019 Dan Shapir on TwitterThe Anubis GatesCharles Max Wood:St. George MarathonVitali Zaidman: Vitali’s websiteArzamas Academy Follow Vitali on Medium and TwitterSpecial Guest: Vitali Zaidman . Support this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

22 Okt 201938min

Tanmai is one of the founders at Hasura. Hasura gives you instant graphQL APIs on top of a Postgres database. The eventual idea is to make data access secure and easy. Tanmai explains the challenges of doing this in the cloud. He talks about some of the difficulties with the tooling around using GraphQL and its bias towards working well with a monolith. Since GraphQL is basically a shared type system that describes your API, that means all your types need to be in the same code base. This is at odds with the folks who want to do microservices and serverless functions, because since their API is split across multiple services they have different types, and forcing these types to work together defeats the purpose of using microservices. Also, storing state across requests doesn’t work well with serverless and cloud native stuff. In short, learning to live without state is one of the general challenges with going serverless. This is where Hasura comes into play, and Tanmai explains how it works. Hasura is metadata driven, and each instance of the server can leverage multiple calls and exhibit a high amount of concurrency. It’s designed to be a little more CPU bound than memory bound, which means that configuring auto scaling on it is very easy and allows you to utilize the elasticity of cloud native applications. Tanmai clarifies his usage of the word ‘cloud native’, by which he means microservices. He explains that when you have a metadata based engine, this metadata has a language that allows you to bring to bring in types from multiple upstream microservices, and create a coherent graphQL API on top of that. Hasura is a middle man between the microservices and the consumer that converts multiple types into a single coherent graphQL API.Next, Tanmai explains how Hasura handles data fetching and a high volume of requests. They also invented PostgresQL, RLS-like semantics within Hasura. He explains the process for merging your microservices into a single graphQL interface. Back on data fetching, Tanmai explains that when the product is an app, preventing an overabundance of queries becomes easier because during one of the staging processes that they have, they extract all of the queries that the app is actually making, and in the production version it only allows the queries that it has seen before. Hasura is focused on both the public interface and private use cases, though private is slightly better supported. Tanmai talks about the customizations available with Hasura. Hasura supports two layers. One is an aliasing layer that lets you rename tables, columns, etc as exposed by PostgresQL. The other is a computer column, so that you can add computer columns so you can extend the type that you get from a data model, and then you can point that to something that you derive. The panelist discusses the common conception of why it is a bad idea to expose the data models to the frontend folks directly. They discuss the trend of ‘dumbing down’ available tooling to appeal to junior developers, at the cost of making the backend more complicated. They talk about some of the issues that come from this, and the importance of tooling to solve this concern. Finally, Tanmai talks about the reasons to use Hasura over other products. There are 2 technologies that help with integrating arbitrary data sources. First is authorization grammar, their version of RLS that can extend to any system of types and relationships, The second is the data wrapper, part of the compiler that compiles from the graphQL metadata AST to the actual SQL AST. That is a generic interface, so anyone can come in and plug in a Haskell module that has that interface and implement a backend compiler for a native query language. This allows us to plug in other sources and stitch microservices together. The show concludes with Tanmai talking about their choice to use Haskell to make Hasura. PanelistsAJ O’NealDan ShapirSteve EdwardsCharles Max WoodWith special guest: Tanmai GopalSponsorsAdventures in DevOpsSentry use the code “devchat” for 2 months free on Sentry’s small plan The Dev Ed PodcastLinksHasuraHaskellNode.jsCloud NativeMicroservices PostGraphile  Postgres PostgresQL RLSSwaggerJAMstackSoapRest Follow DevChatTV on Facebook and Twitter PicksAJ O’Neal:The Economic SingularityCapital CitiesGameCube HomebrewDan Shapir:RomaniaJSCampSteve Edwards:Cold Blooded: The Clutter Family MurdersCharles Max Wood:Maxcoders.ioTripItSt. George MarathonVO2 Max appTanmai Gopal:  Follow Tanmai on Twitter @tanmaigoBroken Earth TrilogyThe Three-Body ProblemgraphQL AsiaSpecial Guest: Tanmai Gopal. Support this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

17 Okt 20191h 10min

JavaScript Jabber celebrates its 400th episode with former host Dave Smith and some other familiar voices. Each of the panelists talks about what they’ve been up to. Dave hasn’t been on the show for 3 years, but he and Jameson Dance have started a podcast called Soft Skills Engineering where they answer questions about the non-technical side of engineering. When he left the show he was the director of engineering on Hire View, and currently he works for Amazon on Alexa. Christopher Buecheler has been on several JSJ, RRU, and MJS episodes. His time is divided between contracting for startups and his own company closebrace.com, a tutorial and resource site for JavaScript developers.  Dan Shapir has also been on JSJ as a guest, and is currently works for Wix doing performance tech. He enjoys speaking at conferences, such as JS Camp in Bucharest, Romania and the YGLF conference. Steve Edwards was previously on MJS 078. He started on Drupal in the PHP world, switched to JavaScript, and then a few years ago he started looking at Vue. Now he does Vue fulltime for ImageWare Systems.As for Charles, his primary focus is the podcasts, since DevChat.tv produces around 20 episodes per week. 5 new shows were started in July, and he talks about some of the challenges that that brought. One of his most popular shows recently was JSJ 389: What makes a 10x Engineer? This helped him realize that he wants to help teach people how to be a successful engineer, so he’s working on launching a new show about it. The panelists share some of their favorite JSJ episodes. They discuss the tendency of JSJ to get early access to these fascinating people when the conversation was just beginning, such as the inventor of Redux Dan Abramov, before their rise to stardom. The talk about the rise in popularity of podcasting in general. They agree that even though JavaScript is evolving and changing quickly, it’s still helpful to listen to old episodes. Charles talks about the influence JavaScript Jabber has had on other podcasts. It has spawned several spinoffs, including My JavaScript Story. He’s had several hosts start their own DevChat.tv shows based off JavaScript Jabber, including Adventures in Angular and The DevEd Podcast. JavaScript Jabber has also been the inspiration for other podcasts that aren’t part of DevChat.tv. There aren’t many podcast companies that produce as many shows as they do and they’re developing their own tools. DevChat.tv moved off of WordPress and is in the process of moving over to Podwrench. Charles talks about all the new shows that have been launched, and his view on ‘competing’ podcasts. Charles is also considering doing an audio drama that happens in a programming office, so if you would like to write and/or voice that  show, he invites you to contact him. The show concludes with the panel talking about the projects they’ve been working on that they want listeners to check out. Christopher invites listeners to check out closebrace.com. He also has plans to write a short ebook on unit testing with jest, considered doing his own podcast, and invites people to check out his fiction books on his website. Dan talks about his involvement with Wix, a drag and drop website service, that recently released a technology called Corvid which lets you write JS into the website you build with Wix. This means you can design your user interface using Wix, but then automate it, add events functionality, etc. Dan is also going to be at the Chrome Dev Summit conference. Dave invites listeners to check out the Soft Skills Engineering podcast, and Charles invites listeners to subscribe to his new site maxcoders.io. Panelists- Dan Shapir- Christopher Buecheler- Steve Edwards- Dave Smith- Charles Max WoodSponsors- https://tidelift.com/- http://sentry.io/ use the code “devchat” for 2 months free on Sentry’s small plan - https://devchat.tv/adventures-in-dotnet/Links- https://devchat.tv/dev-rev/- https://devchat.tv/my-javascript-story/mjs-099-christopher-buecheler/- https://devchat.tv/js-jabber/jsj-338-its-supposed-to-hurt-get-outside-of-your-comfort-zone-to-master-your-craft-with-christopher-buecheler/#viewport- https://devchat.tv/react-round-up/rru-029-christopher-buecheler-getting-ready-to-teach-lessons-learned-from-building-an-84-tutorial-software-course/#viewport- https://devchat.tv/my-javascript-story/mjs-108-dan-shappir/#viewport- https://devchat.tv/js-jabber/jsj-334-web-performance-api-with-dan-shappir/#viewport- https://devchat.tv/js-jabber/jsj-371-the-benefits-and-challenges-of-server-side-rendering-ssr-with-dan-shappir/#viewport- https://devchat.tv/my-javascript-story/mjs-078-steve-edwards/#viewport- https://devchat.tv/js-jabber/179-jsj-redux-and-react-with-dan-abramov/- https://devchat.tv/js-jabber/187-jsj-vue-js-with-evan-you/- https://devchat.tv/js-jabber/jsj-383-what-is-javascript/- https://devchat.tv/js-jabber/jsj-385-what-can-you-build-with-javascript/- https://devchat.tv/js-jabber/jsj-390-transposit-with-adam-leventhal/- https://devchat.tv/js-jabber/jsj-395-the-new-ember-with-mike-north/- https://devchat.tv/js-jabber/220-jsj-teaching-javascript-with-kyle-simpson/- https://devchat.tv/js-jabber/jsj-313-light-functional-javascript-with-kyle-simpson/- https://devchat.tv/js-jabber/124-jsj-the-origin-of-javascript-with-brendan-eich/- https://devchat.tv/js-jabber/073-jsj-react-with-pete-hunt-and-jordan-walke/- https://devchat.tv/js-jabber/jsj-392-the-murky-past-and-misty-future-of-javascript-with-douglas-crockford/- https://player.fm/series/all-javascript-podcasts-by-devchattv/jsj-391-debugging-with-todd-gardner- https://devchat.tv/js-jabber/jsj-389-what-makes-a-10x-engineer/- http://cwbuecheler.com/- https://closebrace.com- https://www.wix.com/corvid  - https://softskills.audio/- https://maxcoders.io/                                                                                                                                                                           Follow DevChatTV on https://www.facebook.com/DevChattv/?__tn__=%2Cd%2CP-R&eid=ARDBDrBnK71PDmx_8gE_IeIEo5SnM7cyzylVBjAwfaOo1ck_6q3GXuRBfaUQZaWVvFGyEVjrhDwnS_tV and https://twitter.com/devchattv?lang=en PicksSteve Edwards:- https://github.com/formio/formioChristopher Buecheler:- https://www.apollographql.com/docs/apollo-server/testing/graphql-playground/- https://twitter.com/TheTimeCowboy Jake Lawrence Charles Max Wood:- https://www.stgeorgemarathon.com/-Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

15 Okt 20191h 10min

Valeri Karpov is a maintainer on Mongoose, has started a few companies, and works for a company called Booster Fuels. Today’s topic debugging with Async/Await. The panel talks about some of the challenges of debugging with Async. AJ, however, has never encountered the same problems, so he shares his debugging method. Valeri differentiates between .catch vs try...catch, and talks about why he prefers .catch. There are two ways to handle all errors in an async function without leading to an unhandled promise rejection. The first is to wrap the entire body of the async function in a try...catch, has some limitations. Calling an async function always returns a promise, so the other approach is calling .catch on the promise to handle any errors that occur in that function body. One of the key differences is if you return a promise within an async function, and that return promise is wrapped in a try...catch, the catch block won’t get called if that promise is rejected, whereas if you call .catch on the promise that the function returns, you’ll actually catch that error. There are rare instances where this can get tricky and unintuitive, such as where you have to call new promise and have resolve and reject, and you can get unexpected behavior.The panel discusses Valeri’s current favorite JS interview question, which is,  “Given a stream, implement a function called ‘stream to promise’ that, given a stream, returns a promise that resolves to the concatenation of all the data chunks emitted by the stream, or rejects if the stream emits an error event.” It’s really simple to get this qustion right, and really simple to get it wrong, and the difference can be catastrophic. AJ cautions listeners to never use the data event except in the cases Val was talking about, only use the readable event.The conversation turns to the function of a readable event. Since data always pushes data, when you get a readable event, it’s up to you to call read inside the function handler, and then you get back a chunk of data, call read again and again until the read returns null. When you use readable, you are in control and you avoid piling functions into RAM. In addition, the right function will return true or false to let you know if the buffer is full or not. This is a way to mix imperative style into a stream.The next discussion topics are the differences between imperative style and reactive style and how a waits and promises work in a normal four loop. A wait suspends the execution of a function until the promise is resolved. Does a wait actually stop the loop or is it just transpiling like a promise and it doesn’t stop the loop. AJ wrote a module called Batch Async to be not as greedy as promise.all but not as limited as other options.The JavaScript panelists talk about different async iterators they’ve used, such as Babel. They discuss the merits of Babel, especially since baseline Android phones (which a significant portion of the population of the world uses) run UC Browser that doesn’t support Babel, and so a significant chunk of the population of the world. On the other hand, if you want to target a large audience, you need to use Babel.Since frameworks in general don’t handle async very well, the panel discusses ways to mitigate this. They talk about different frameworks like Vue, React, and Express and how they support async functions. They discuss why there is no way for you to actually cancel an async option in an actual case, how complex canceling is, and what you are really trying to solve for in the cancellation process. Canceling something is a complex problem. Valeri talks about his one case where he had a specific bug that required non-generic engineering to solve, and cancelling actually solved something. When AJ has come across cancellation issues, it’s very specific to that use case. The rest of the panelists talk about their experiences with having to cancel something. Finally, they talk about their experience with async generator functions. A generator is a function that lets you enter into the function later. This makes sense for very large or long running data sets, but when you have a bounded items, don’t complicate your code this way. When an async generator function yields, you explicitly need to call next in order for it to pick up again. If you don’t call ‘next’, it’s essentially cancelled. Remember that object.keys and object.values are your friends. PanelistsChristopher BuechelerAJ O’NealCharles Max WoodWith special guest: Valeri KarpovSponsorsThe DevEd PodcastSentry use the code “devchat” for 2 months free on Sentry’s small plan Adventures in DevOpsLinksMongooseExpress 5Node StreamsPull StreamsMasteringjs.ioMongoDBBabelHTMLWebpackVueExpressRxJSConsole.logJson.stringifyBatchasync.jsHow to Write Batch Async Functions Follow DevChatTV on Facebook and Twitter PicksAJ O’Neal:Ethan Garofolo YouTubeChristopher Buecheler:Functional Design Patterns for Express.jsCharles Max Wood:Microsoft IgniteMaxcoders.ioValeri Karpov: Follow Valeri on Twitter @code_barbarian and Github @vkarpov15Masteringjs.ioJurassic Park: A NovelSpecial Guest: Valeri Karpov. Support this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

10 Okt 20191h 3min

Guest Paige Niedringhaus has been a developer full time for 3 years, and today she is here to talk about Node 12. One of the things she is most excited about is the ES6 support that is now available, so things that used to require React, Angular, or Vue can now be done in Node. The require function will not have to be used in Node 12. AJ is worried about some of these changes and expresses his concerns. Paige assures him that in the beginning you won’t have to switch things to imports. You may have to change file extensions/types so Node can pick up what it’s supposed to be using. They are also trying to make it compatible with CommonJS.Node 12 also boasts an improved startup time. The panel discusses what specifically this means. They talk about the code cache and how Node caches the built in libraries that it comes prepackaged with. The V8 engine is also getting many performance enhancements. Paige talks about the shift from promises to async. In Node 12, async functions will actually be faster than promises. They discuss some of the difficulties they’ve had in the past with Async08, and especially callbacks. Another feature of Node 12 is better security. The transcripted security layer (TLS), which is how Node handles encrypted strains of communication, is upgrading to 1.3. The protocol is simpler to implement, quicker to negotiate sessions between the applications, provides increased end user privacy, and reduces request time. Overall, this means less latency for everybody. 1.3 also gets rid of the edge cases that caused TLS to be way far slower than it needed to be. The conversation turns to properly configuring default heap limits to prevent an ‘out of memory’ error. Configuring heap limits is something necessary when constructing an incredibly large object or array of objects. Node 12 also offers formatted diagnostic summaries, which can include information on total memory, used memory, memory limits, and environment lags. It can report on uncaught exceptions and fatal errors. Overall, Node 12 is trying to help with the debugging process. They talk about the different parsers available and how issues with key pairing in Node have been solved. Paige talks about using worker threads in Node 12. Worker threads are really beneficial for CPU intensive JavaScript operations. Worker threads are there for those things that eat up all of your memory, they can alleviate the load and keep your program running efficiently while doing their own operations on the sideline, and returning to the main thread once they’ve finished their job. None of the panelists have really used worker threads, so they discuss why that is and how they might use Worker Threads in Node 12. In addition, Node 12 is making Native module creation and support easier, as well as all the different binaries a node developer would want to support. Paige makes it a point to mention the new compiler and minimum platform standards. They are as follows:GCC minimum 6GLIVC minimum 2.17 on platforms other than Mac and Windows (Linux)Mac users need at least 8 and Mac OS 10.10If you’ve been running node 11 builds in Windows, you’re up to speedLinux binaries supported are Enterprise Linux 7, Debian 8, and Ubuntu 14.04If you have different requirements, go to the Node websitePanelistsJ.C. HyattSteve EdwardsAJ O’NealWith special guest: Paige NiedringhausSponsorsTideliftSentry use the code “devchat” for 2 months free on Sentry’s small plan Sustain Our SoftwareLinksAsyncCommonJSnjsPromiseNodeEvent StreamllhttpllparseLLVMPapa ParseJson.stringify Json.parseOptimizing Web Performance TLS 1.3Overlocking SSLGenerate Keypair Follow DevChatTV on Facebook and Twitter PicksJ.C. Hyatt:AWS Amplify framework12 Rules for Life: An Antidote to Chaos by Jordan PetersenReact and Gatsby workshopsSteve Edwards:The Farside comic coming back?AJ O’Neal:Field of Hopes and StringsLink’s AwakeningDunePaige Niedringhaus:DeLonghi Magnifica XS Automatic Espresso Machine, Cappuccino MakerCONNECT.TECH Conference Follow Paige on Twitter, Medium, and Github Special Guest: Paige Niedringhaus. Support this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

8 Okt 20191h 4min

Kaelig Deloumeau-Prigent is a self taught web developer from west France. He has worked for BBC, The Guardian, and The Financial Times in the UK. He has also worked in the US for SalesForce and currently works for Shopify on their Polaris design system. Shopify has multiple design systems, and Polaris is open source. Today the panel is talking about design systems and developer tooling around design systems. To begin, Kaelig explains what a design system is. A design system is all of the cultural practices around design and shipping a product. It includes things like the words, colors, spacing grid system, and typography, plus guidance on how to achieve that in code. The panelists discuss what has made design systems so popular. Design systems have been around for a while, but became popular due to the shift to components, which has been accelerated by the popularity of React. The term design system is also misused by a lot of people, for it is much more than having a Sketch file. Next, they talk about whether design systems fall under the jurisdiction of a frontend developer or web designers. Kaelig has found that a successful design system involves a little bit of everyone and shouldn’t be isolated to one team. They talk about what the developer workflow looks like in a design system. It begins with thinking of a few common rules, a language, and putting it into code. As you scale, design systems can become quite large and it’s impossible for one person to know everything. You either give into the chaos, or you start a devops practice where people start to think about how we build, release, and the path from designer’s brain to production.The panelists then talk about how to introduce a design system into a company where there are cultural conflicts. Kaelig shares his experience working with SalesForce and introducing a design system there. They discuss what aspects of a design system that would make people want to use it over what the team is currently doing. Usually teams are thankful for the design system. It’s important to build a system that’s complete, flexible, and extensible so that you can adapt it to your team. A good design system incorporates ‘subatomic’ parts like the grid system, color palette, and typography, referred to as design tokens. Design systems enable people to take just the bits of the design system that are interesting to them and build the components that are missing more easily. The conversation turns to the installation and upgrade process of a design system. Upgrading is left up to the customer to do on their own time in most cases, unless it’s one of the big customers. They talk about the role of components in upgrading a design system. Kaelig talks about the possibility of Shopify transitioning to web components. Kaelig shares some of his favorite tools for making a design system and how to get started making one. A lot of design teams start by taking a ton of screen shots and looking at all the inconsistencies.Giving them that visibility is a good thing because it helps get everyone get on the same page. The panelists talk about the role of upper management in developing components and how to prioritize feature development. Kaelig talks about what drives the decision to take a feature out. The two main reasons a feature would be removed is because the company wants to change the way things are done and there’s a different need that has arisen. The show concludes by discussing the possibility of a design system getting bloated over time. Kaelig says that Design systems takes some of the burden off your team, help prevent things from getting bloated, allow you to ship less code. PanelistsChris FerdinandiAimee KnightSteve EmmerichWith special guest: Kaelig Deloumeau-PrigentSponsorsSustain Our SoftwareSentry use the code “devchat” for 2 months free on Sentry’s small plan Adventures in BlockchainLinksShopify PolarisBootstrapReactSketch.uiFigma.ui CSSStoryBookESLintJestEnsignWebpacker Follow DevChatTV on Facebook and Twitter PicksSteve Emmerich:CedarWorks play beds  Azure’s container instancesAimee Knight:Awesome Actions for GithubChris Ferdinandi:Free Meek docuseriesSimplicity: Part 2 by Bastian AllgeierKaelig Deloumeau-Prigent:DependabotInk by Vadim Demedez Follow Kaelig on Twitter @kaeligSpecial Guest: Kaelig Deloumeau-Prigent. Support this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

3 Okt 201939min

Jonathan Lee Martin is an instructor and developer. He got his start in teaching at Big Nerd Ranch doing 1-2 week trainings for mid to senior developers, and then transitioned to 16 week courses for career switchers. He also worked for Digital Crafts for a year, and then wanted to focus on building out his own personal teaching brand. One of his first steps toward building his own brand was to publish his book, Functional Design Patterns for Express.js.The inspiration for Jonathan’s book came from his experience teaching career switchers. He wanted to experiment in the classroom with teaching functional programming in a way that would be very approachable and applicable and dispel some of the magic around backend programming, and that became the template for the book. Jonathan loves the minimalist nature of Express.js and talks about its many uses. He believes that it knowing design patterns can take you pretty far in programming, and this view is related to his background in Rails. When he was working in Rails taming huge middleware stacks, he discovered that applying design patterns made builds take less time. He talks about other situations where knowing design patterns has helped. Express.js leans towards object oriented style over functional programming, and so it takes to these patterns well. Express.js has its shortcomings, and that’s where Jonathan’s favorite library Koa comes into play. The conversation switches back to Jonathan’s book, which is a good way to start learning these higher level concepts. He purposely made it appealing to mid and senior level programmers, but at the same time it does not require a lot of background knowledge. Jonathan talks about his teaching methods that give people a proper appreciation for the tool. Jonathan talks more about why he likes to use Express.js and chose to use it for his book. He cautions that his book is not a book of monads, but rather about being influenced by the idea of composition over inheritance. He talks about the role of middleware in programming. The panel asks about Jonathan’s toolchain and approach to writing books, and he explains how his books are set up to show code. They discuss the different forms required when publishing a book such as epub, MOBI, and PDF. Jonathan found it difficult to distribute his book through Amazon, so he talks about how he built his own server. Charles notes that your method of distributing your book will depend on your goal. If you want to make the most money possible, make your own site. If you want to get it into as many hands as possible, get it on Amazon.Many of the JavaScript Jabber panelists have had experience publishing books, and Jonathan shares that you can reach out to a publisher after you’ve self-published a book and they can get it distributed. Jonathan believes that If he had gone straight to a publisher, he would have gotten overwhelmed and given up on the book, but the step by step process of self-publishing kept things manageable. The panelists discuss difficulties encountered when publishing and editing books, especially with Markdown. Jonathan compares the perks of self-editing to traditional editing. Though he does not plan to opensource his entire editing pipeline, he may make some parts available. The show concludes with the panelists discussing the clout that comes with being a published author. PanelistsCharles Max WoodChristopher Buecheler J.C. HyattWith special guest: Jonathan Lee MartinSponsorsAdventures in BlockchainSentry use the code “devchat” for 2 months free on Sentry’s small plan The Freelancers’ ShowLinksBig Nerd RanchDigital CraftsJSJ 070: Book Club JavaScript Allonge with Reginald BraithwaiteJavaScript Allonge by Reginald BraithwaiteFunctional Design Patterns for Express JS by Jonathan Lee MartinNode.jsExpress.jsKoaMinjs  SinatraHttp.createserverMonadsMiddleware  MarkdownPandocDiff-match-path libraryEpubMOBILaTeX Stripe CheckoutFstoppersSoftcoverBookseller API  Follow DevChatTV on Facebook and Twitter PicksChristopher Buecheler:Cluisbrace.com newsletterJ.C. Hyatt:Corsair wireless charging mouse padCharles Max Wood:Magnetic whiteboard basketsMrs. Piggle-Wiggle booksJonathan Lee Martin:Eric Elliot JSYellowScale Follow Jonathan and find his book at jonathanleemartin.comSpecial Guest: Jonathan Lee Martin. Support this podcast at — https://redcircle.com/javascript-jabber/donationsPrivacy & Opt-Out: https://redcircle.com/privacyBecome a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

1 Okt 201958min