HTML All The Things - Web Development, AI, and Developer Careers

In this episode Matt discusses when you should put down the books and just start coding away on your creation. It can be difficult to tell when you should dive into a project and get your hands dirty when there is so much to learn, however, it's important to remember that no matter how much you read, there will always be something that you've never seen before on every project. After getting a basic knowledge of what you're working on, you're generally better off just starting the code and researching/reading as needed throughout the project. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and special guest Sean from Rabbitwerks JavaScript discuss a whole lot about UX. They go through whether technology is making us lazier as a species due to things like smart homes and home automation. Then they change gears and discuss utilitarian UX and how it related to wearables as a whole and their sales. Then finally in the Web News they discuss the very difficult balance of networking, social media, and attending events versus putting your nose to the grindstone for some long-term focused work session - diving into the business owner's UX juggling both these conflicting needs. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt clears the air between HTML All The Things and WordPress. Having not been given the warmest of welcomes in episodes past, Matt goes over the pros and cons of WordPress specifically touching on the areas that many developers question such as too many plugins, plugin conflicts, bloated websites, and security. Then he explores the advantages that WordPress has over the competition, listing a variety of strengths and use cases that you'd be hard pressed to find anywhere else. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and Mike discuss the difference between various types of websites including static states, server side rendering, and single page apps. With so many different ways to code up and deliver websites to users, the choice isn't always simple. Performance, infrastructure/hosting type, and of course the learning curve all play a factor in what type of website you'll create for your users. This episode goes over some of the technologies at play with each type. Then later in the weekly Web News segment, we discuss the HTML All The Things website and how the project has evolved over time before coding has even begun. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and Mike discuss what JSON is in comparison to similar technologies like XML. They also cover common JSON uses like using APIs to get information and how to store it efficiently. Finally in the Web News they discuss business growing pains, when adopting new software, accommodating emerging needs, and figuring out when it's time for an upgrade. Episode Sponsor One Membership by Template Monster Follow this link (https://tinyurl.com/htmlallthethings) and use our promo code (htmlallthethings10) for 10% off. We receive a monetary kickback for sales using our link and promo code. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and Mike discuss another collection of UX considerations including Unseen UX and Forgotten UX. Unseen UX includes experiences such as ABS in a car, where the user has very little control over it, has very little feedback from it, and expects it to produce a result automatically. Forgotten UX typically has standard feedback on a screen, or audio of some kind, but it can be ignored completely and will eventually be forgotten over time - this type of UX can be seen with many face unlock technologies on smartphones and on-screen fingerprint readers. Show Notes: https://htmlallthethings.com/Podcast/5db0b63e6a070d0011eb6583 You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and Mike discuss one of the most difficult things that any web development professional faces - the price. Prices range from a few thousand to just a few hundred on the exact same project depending on which company you go with, with fluctuation like that it can take years before you're confident in your pricing even a little bit. This episode features two fully featured example scenarios, strategies, and some other tips that should help you up your pricing game for years to come. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and Mike sit down with Eric Normand to discuss his new book Grokking Simplicity. Throughout the episode they discuss early access book releases, blogging & writing tips, and cover a tonne of ground on functional programming including how to get started and how to apply the paradigm to a problem. Show Notes: https://htmlallthethings.com/Podcast/5d9e35fe6a070d0011eb657f You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and Mike discuss the differences and similarities between web development and native app development. More specifically discussing technologies like Apache Cordova, Flutter, React Native, and many others. On top of these technologies, they also discussed the different procedures that web developers vs native app developers have to take to get their product off the ground, including testing on various devices and the performance of cross-platform vs native development. Then they switch gears to discuss the UX of smartphones on different types of apps in the weekly Web News. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and Mike discuss learning UI development from scratch covering topics such as DOM flow (normal flow), different learning methods (YouTube, written guides, traditional courses), and practicing your knowledge through repetitive examples. Then they switch gears to discuss all the newfangled gadgets and gizmos that can be found in modern cars via the weekly Web News segment. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and Mike discuss making web development easier through the use of various methodologies, libraries, frameworks, new technologies, and more. By ensuring that you're using the right tools and having your development environment tweaked just so, you can save a bunch of time, and in some cases actually do a better job. Then for the weekly Web News, they discuss "Hustle Overload" speaking specifically about side hustles, full time hustles, and whether or not you should be doing multiple of them, or whether you should be managing your work/life balance. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and Mike discuss the user experience, otherwise known as UX. Specifically, their top 3 UX considerations for UX designers/experts. These considerations include things like the newcomer effect, familiarity, and evolution & respect. They're aimed to be sort of an analysis of the unspoken rules of UX that can easily go overlooked, complete with examples from popular companies like Facebook and YouTube. Then they switch gears to this week's Web News asking how responsible a company is to its product in terms of warranty, defects, and engineering. Show Notes: https://htmlallthethings.com/Podcast/5d794c736a070d0011eb6579 You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and Mike discuss developer burnout including how to identify the signs of burnout, what the result of burnout is, and how to avoid it the best you can. Then they switch gears to discuss the innovations of the tech world zeroing in on whether or not the mainstream devices are stifling innovation due to their popularity. Show Notes: https://htmlallthethings.com/Podcast/5d7004be6a070d0011eb6577 You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and Mike discuss the creation process that drives most of their website work. Since Digital Dynasty Design is a small team they can easily tailor the customer experience individually so that customers save money and get their products faster. This tailored experience often times includes manipulating the initial creation process that is used to determine the customer's needs, wants, and goals through the production and review of wireframes, mockups, and prototypes as needed. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode of The Sisterhood of the Traveling Developer Pants, Matt and Mike discuss the equipment and lifestyle of a developer that likes to travel. We cover things like what to pack, managing workload on the road, as well as doing meetings in different time zones. After all that we discuss WearOS focusing on where it sits in the smartwatch market, alongside what improvements it needs to stay relevant. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and Mike discuss 10 tips that every beginner web developer needs to hear. These tips cover a variety of topics including UI/UX concepts, learning new skills, website planning/brainstorming, wireframing software, IDE software, version control (git), and much more. Then we switch gears and discuss whether or not you should be purchasing the latest and greatest flagship device (ie Samsung Galaxy Note 10+), or if you should purchase a more budget-conscious device. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and Mike discuss something that plagues a lot of web developers, being a jack of all trades. As a web developer you're expected to know a lot of information on not only making up the user interface, but also the databases, hosting platforms, and even design principles that makeup the websites you build. Some of this can be alleviated if you work in a large team where responsibilities are spread across multiple specialists, but for freelancing and small business you need to wear all the hats to become successful. Being a jack of all trades without a mastering a single one can also make you experience some impostor syndrome due to all the hours you've spent getting this far in your career. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and Mike sit down with Knut Melvær, the Head of Developer Relations at Sanity.io to discuss all things headless CMS. The headless CMS is a unique way to add content to your website utilizing your choice of front-end technologies and an API to populate the site with your content. We touch on the comparisons between Sanity.io and other popular CMS out there, alongside thing its advantages, weaknesses, and unique feature set in the market. If you've ever been interested in checking out a headless CMS, but are wondering how it compares to the CMS you're using now (probably WordPress), then you're not going to want to miss this episode. Show Notes: https://htmlallthethings.com/Podcast/5d41e97d6a070d0011eb656d You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and Mike discuss how they manage varying amounts of workload across different projects and customers. Time management, project management, and priority setting are all extremely important when it comes to managing your workload. Not only do you have to reach the deadline in time, but you also have to ensure you make a quality product and maintain face with good customer service. Everyone has their own unique spin on how they manage their workload and with Matt and Mike it's no different. If you've ever felt swamped - and we all have - then this episode is packed with tips and tricks to help manage your time effectively. Show Notes: https://htmlallthethings.com/hub/Podcast/5d38b3216a070d0011eb656b You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this week's Tidbit/Web News we discuss a viral tweet that recently stirred up controversy among the programming community. This tweet named a particular type of individual called a "10x Engineer" You can find the original Tweet here: https://twitter.com/skirani/status/1149302828420067328 You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode of the podcast, Matt and Mike discuss tackling the new HTML All The Things website with Sanity.io, Nuxt.js, and Netlify. Rather than the standard cPanel hosting, or the existing setup with Digital Ocean, this deployment is going to be completely within the free tiers of these offerings with the ability to scale as the website gains traction. In addition to the discussion around these technologies, this episode does a deep dive into the UI/UX planning of the website, going over the recently completed wireframes that house a variety of design choices that should help the user navigate the site easier while updating the site to a more modern layout. This episode is a great resource for anyone that is curious about the planning procedure that goes into making a website in a small team. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

Making websites require a lot of different skills from the folks in the office acquiring the job, to the developers and designers that make the website work, then to the marketing officials that make the website popular. Often times freelancers, or small businesses are unable to cover all the bases when it comes to all these skill sets, leaving rather large holes in their company's tool set. Luckily there are a variety of ways to avoid these issues, each one offering a unique set of pros and cons depending on the situation at hand. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and Mike discuss something that's currently stumped the development of the HTML All The Things website - the CMS. Originally planned as a Vue.js UI alongside a custom admin panel, the new plan for the website has raised some questions that all web developers have faced at some point in their career. Should you reinvent the wheel with a fully custom solution? Or should you get up and running quickly and find a pre-built solution? Show Notes: https://htmlallthethings.com/Podcast/5d1d0e4b6a070d0011eb6565 You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode Matt and Mike discuss JavaScript in all its glory. They go over things like how beneficial vanilla JavaScript is to learn, especially when you're first starting out, and also explore why you shouldn't dive straight into learning a framework without knowing the basics. Then for our Web News segment, we have Sean from Rabbitwerks JavaScript call in for a discussion on the changes that VueJS 3 bring to the table and the controversy surrounding those changes. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode, Matt and Mike discuss the often stressful task of migrating an infrastructure to a new home. With the very real fear of downtime, issues, or data loss on the line, it's important to take the appropriate steps to give you the best chance of success. Furthermore, having a few backup plans is also a good idea should the migration hit a snag, or fail in some way. To finish off the episode, Mike takes us through the current status of laptops and desktops, discussing the hardware that's available today and what kind of computer you should be buying based on your needs. Show Notes: https://www.htmlallthethings.com/Podcast/5d0a82b46a070d0011eb6561 You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this episode, Matt and Mike discuss freelancing, contracting, and remote work some of the most important and quickly growing segments in the web development industry. Web developers often find themselves trying to decide between a traditional job and freelancing their skills out on their own. While freelancing sound lucrative and exciting, traditional jobs offer more stability and benefits that are generally not found elsewhere. We discuss these pros and cons of each of these pathways, and then change gears to discuss influencers and their affect on the social media platforms that we all use. Show Notes: https://htmlallthethings.com/hub/Podcast/5d0156cd6a070d0011eb655f You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

This week we sit down with Chris Dayley a digital marketing entrepreneur that helps businesses succeed online. We discuss a bunch of very interesting topics including things like SEO, conversions, A/B testing, and PPC. This episode is a great resource for any web developer, or online entrepreneur, that needs to brush up on their marketing skills. Show Notes: https://www.htmlallthethings.com/Podcast/5cf825c86a070d0011eb655d You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit | Discord

In this week's episode, Matt and Mike discuss why procedures and standard practices are important. Every entrepreneur at some point in their career has tried to turn themselves against the bureaucracy and slow systems that drive large corporate machines only to find themselves needing similar systems to keep themselves afloat. We'll be discussing this sort of realization and how a business can slowly, yet naturally, create unique procedures that compliment their work style. Then we change things up with a length discussion on digital wellbeing again, but this time we talk about the plethora of digital wallets and their associated apps and loyalty cards. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit

In this episode Matt and Mike discuss something we've all felt at one time or another - Imposter Syndrome. Whether it's due to lack of experience, or tackling a brand new topic, imposter syndrome can zap your motivation and make you want to quit. While it's hard to overcome, it's important to note that everyone has experienced it at some point in their career and will almost definitely experience it again. We offer our stories alongside some tips to overcome the dread and emerge a better developer and entrepreneur. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit

In this episode of the podcast Matt and Mike discuss the future of web development focusing on emerging trends and new technologies that are ready to take the world wide web by storm. Things like Motion UI, Progressive Web Apps (PWA), blockchain, voice search integration, and much more! With so much functionality being put into web developers' hands the future looks bright, but performance is a big concern with sites getting heavier and heavier as the years go by. Full show notes: https://www.htmlallthethings.com/Podcast/5cdc53536a070d0011eb6557 You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit

In this episode of the podcast, Matt and Mike discuss CSS frameworks, with a particular focus on Bootstrap, Materialize, and Tailwind CSS. Each of these frameworks comes with their own pros and cons that make them a great fit for particular projects offering UI developers a bunch of options when choosing the tools they need for a given project. Full show notes: https://www.htmlallthethings.com/hub/Podcast/5cd34bab2c5a92001836b76b You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit

In this episode Mike and Matt discuss selecting, purchasing, and shopping for the equipment you need to get the job done. Whether you're on a budget, or ready to spend a bunch of money on something fancy, this episode covers how to make sure you get the most bang for your buck. We start off discussing the balance between pricing, your use-case, and future proofing, then we lay out ways to ensure you get all the features you need, followed by a discussion on some specific peripherals and equipment that you'll most likely encounter in the web development field. To top it off, we end with our recurring Web News segment, this week covering the various app install methods (PWA, app store, web app, browser) that are available on different devices, and which one is the most "legitimate" or more specifically, which one do you use depending on what the app does. Full show notes can be found here: https://www.htmlallthethings.com/hub/Podcast/5cc9e4282c5a92001836b769 You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit

This week our episode was cut short and released late due to a bit of a fiasco with our only in-house MacBook. We're also using this opportunity to announce some changes that we're going to be applying to future episodes based on some feedback that we've received. If you're a fan of our Web News segment, this week the episode was dominated by a discussion around exactly what happened to our MacBook and the various attempts we made to fix the issue. A standard full episode is planned for next week.

In this episode we sit down once again with David Lindahl to discuss his full time job and many side hustles. Segment 1 - What’s New? Tell us a little bit about yourself and what’s happened since we last spoke. Segment 2 - UI Developer How long did it take you to fully settle into your role? Before you got a full time position you were working on a variety of side hustles, many of which are still online today. How was the transition from being your own boss to working under a company? Is there any sort of issue with you running side hustles and working at your day job? Conflict of interest? Do they own a piece of that income as apart of an agreement? How fast were you expected to “spin-up” when you were hired? For example, were you just thrown a bunch of work and expected to know how to do it on the first day/week? How are the hours? Are you doing a lot of overtime? If so, is it mandatory? Which do you prefer? Working a day job, or being your own boss? How involved are you in the work environment? (ie company sports teams and events) Do you recommend being active within a company in this way? Segment 3 - Side Hustles What side hustles do you have going on? Are you planning on generating a passive income from these projects, or do you have different goals in mind? Rainier Watch is a big side hustle that seems to be getting bigger all the time, what’s your secret? Any tips and tricks for people that are trying to build a side hustle on Instagram? How’s your work/life balance work out with your day job and side hustles together? Are you planning for your side hustles to eventually take over your day job and becoming your full time occupation? Web News - Organic vs Algorithm on Social Media Whenever you look up growing on social media, most of the advice is specifically for exploiting the algorithm in some way With that being said you need to have a good amount of content ready to go so that you actually have something to post, understanding how the algorithm works is great, but if you don’t have anything to post then you can’t get any exposure at all. In terms of content, higher quality is obviously preferred, but if it doesn’t generate good numbers then it seems like putting in the extra time for quality isn’t worth it How much time should you spend on your content? Should you just keep posting quality content and expect results over time - with consistent posting? Should you be prioritizing algorithm “hacks” to get your content more exposure? Is there a balance between using the algorithm and organically making quality content? Should you work on getting a following on multiple networks (ie Instagram, Twitter, Facebook) or should you focus on one? David's Links "Made With Spark: https://madewithspark.com (The MVP site David mentioned in the show) - New website coming really soon" RainierWatch - https://www.rainierwatch.com Basecamp - https://basecamp.com You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit

In this episode Matt and Mike discuss when to start your business, a project, or whatever it is you're putting off. It's easy to get bogged down, luckily there are some tips and tricks to prevent it. Segment 1 - When to Start One of the things you’ll hear as an entrepreneur, and we’ve mentioned on the show several times is to “just start” This means that instead of being bogged down by “what ifs” that you should just jump in and get started on whatever it is you’re working on A prime example: a would-be entrepreneur gets stuck reading into the basics of how to start a business, what pitfalls could happen, what issues may occur, etc. While it’s good to be prepared, you could read for years upon years and still have things to flip through. It’s generally better to understand the basics, do your best to cover all the bases that you need to and then just start - avoiding the paranoia of reading all the laws and issues that others have fallen into in the past. Definitely read and understand these things, but there is a point where you’ve read enough and it’s time to take action, there’s no way you can cover every base all the time or else you’ll never get started Keep in mind that being cautious isn’t a bad thing either, if you think you need to check a law or regulation out before doing something, then it’s best to check to ensure you’re operating legally. Just don’t get bogged down for years without acting, or your competition will fly by you. If you need to, get a lawyer to explain things to you in everyday terms so you can move forward with peace of mind Now that, that’s out of the way and you’re ready to get programming your new app, website, or whatever other program you’re working on, you’re bound to hit another wall - the learning curve Unless you’re experienced in everything your project needs, you’ll end up hitting a lot of walls, maybe you don’t even know where to start and this is another major point of contention that people get stuck in. Let’s say you want to make a PWA and you’re not experienced at all with service workers - a situation we recently found ourselves in - you could read example after example, look at tons of different solutions, try different plugins and even try different programming languages but at the end of the day you’re just reading up on what you want to be doing, you’re not doing what you want to be doing. Obviously guides, tutorials, and research do go a long way and are very valuable, but it’s easy to get stuck reading through the plethora of different ways that you can implement a solution for your given app and if it’s a passion project you want to make sure you’re using the best solution so you keep looking through different options and never actually start making that service worker (in our example) This is another major area where you need to “just start” The time differs from person to person, and from project to project, but at the end of the day you need/want to make that deliverable and we’re all human so it’s not going to be perfect (especially if you’re a beginner), so read up enough so you can navigate Google searches on that thing you’re working on and then just start making it If you end up pivoting a few times, who cares, as long as you keep moving towards the goal - you’ll end up learning way more working on the solution rather than just reading about it As a I said above the “just start” point is different for each person, and furthermore per project - in the next two segments we’ll be discussing our differing approaches to this problem Segment 2 - Matt’s Process When we first started our business, we had a hard time trying to figure out exactly what we needed to do We weren’t sure whether you needed a lawyer, or if you had to declare your business somewhere - there was nothing of the sort covered in our schooling other than the different types of businesses like partnerships, corporations, etc. We ended up calling a few places that didn’t get back to us, so we ended up having a meeting with a lawyer which gave us some information on opening, what at the time, was an IT business From that though, we decided that we wanted to go into web development due to an opportunity that popped up and from that pivot we ended up finding a business advisor that took us through the procedure, which ended up being very easy to get started We’ve mentioned this origin story in a past episode, but it’s an example of how we got bogged down in the beginning, but kept pushing through and then eventually just got started - later than we wanted - but we still finally got the job done In terms of a web development project, one of the more recent examples that we’ve mentioned on that show was learning about service workers, which resulted in getting bogged down in the research - my procedure for this was: Google “service workers” and read up on the very basics, learn how they work and how to implement them at a very high level so I know what tools I’ll need to have at my disposal U

In this episode we'll be discussing the ins and outs of progressive web apps including what they are, some of their functionality, and what challenges/limitations they still face. Segment 1 - What is a PWA As mentioned on the show a few times before, PWA stands for Progressive Web App, which is the evolution of the standard web app If you’re new to all of this, the breakdown is rather simple: Website - A website is a more basic presence on the web, it delivers content to a visitor (ie blog posts, news articles) Popular examples would be news websites, tech blogs, marketing websites, and small business sites. Web App - Functions similarly to a website, however, acts more like an app that you’d see on your phone that performs a function. For example, there are online image editors where you can upload your photo and edit it right in the browser. This editor is a web app because the user interacts with it and computing happens (via the photo edits), content isn’t being delivered in the same way as a written article, or marketing information to the user. Unlike apps that run on your phone however, web apps are limited by the browsers limitations meaning that natively they can’t be installed, and they generally don’t have access to certain functions that natively installed apps can take advantage of, usually due to permissions/security on a given device. Progressive Web App - PWAs are the natural evolution of the standard web app, whose arguably biggest feature is the ability to run offline through the usage of service workers. Basically, they’re a web app that runs in the browser like any other, however, they can be installed and start leveraging more of those features that natively installed Android apps can . They’re still limited by the same restraints you can see from other webview apps and they still run the same codebase as their web app counterparts, not the native Java like other Android apps. In addition, they aren’t in a centralized location like the apps found in the Google Play store, you generally have to grab them from the web app’s website. If you visit the Twitter web app from your Chrome browser on Android you’ll see an “Add to Home Screen” button, if you do that you’re installing the Twitter PWA, but if you look up Twitter in the Google Play Store that’s a different native app PWAs are getting more and more powerful and a lot of the walled off features are being broken down. Just a few short years ago you couldn’t get push notifications from your browser, now they’re rather commonplace for chat and news sites. Accessing hardware was also an issue years ago, getting access to things like a webcam or a microphone, but now you can use a chat app like Skype right in the browser via video or voice chat - these limitations are quickly being done away with. Things like NFC access, however, is still a limitation last time I checked. In terms of accessing PWAs, as mentioned before, there isn’t a centralized location for them all. Unlike on Android where the Google Play Store houses the vast majority of the available native apps, PWAs are generally downloaded from the web app’s website. However, even this limitation is starting to change with new ways to list PWAs in both the Google Play Store and Microsoft Store starting to make their way into the developer toolbelt With these restrictions breaking down the main limitation is really with the codebase. Since a PWA isn’t written in the native language of a given platform, but rather runs more like a website/web app, Javascript does come with some limitations namely that it is a single-threaded process. However, there are workarounds for this, and Javascript itself is becoming more user friendly and more functional with every release - just like PWAs From my experience, iOS has “less adopted” PWAs as of right now, however, I can see that limitation being lifted at some point in the near future in my opinion. One example would be that No BS News for Reddit can be installed on Android phones in it’s demo form right now, but that’s not the case on an iPhone. However, the app does still function in the browser which shows off the versatility of a PWA Another thing to keep in mind is that a lot of corporations will have strict policies on what they support. For example, some places may say that if a certain browser’s usage worldwide is above 2% then that browser must be supported. This creates a problem because oftentimes it’s an older version of a browser like Internet Explorer, and since PWAs are so new, there will be severe limitations on what a developer can do if he needs features to work on such old software In conclusion, a PWA is the evolution of the standard web app. It runs in the browser like any other website/web app, but has additional features like offline functionality and the ability to be installed. PWAs are quickly approaching the functionality of standard native apps, which is good news for small developer teams that have a web app and no ti

In this solo episode, Mike discusses the code refactoring process and then deep dives on work/life balance. Segment 1 - What is Refactoring Refactoring definitionChanging your code to improve its organization and structure without directly influencing it’s performance Explanation of terminologyCode SmellsSomething you notice as your coding that you think will later require a restructure/reorganization ExtensibilityAbility to later down the road use your current code to extend the capabilities of your program without having to rewrite large portions of code Maintainability Make it easier to fix bugs and find issues in your code down the line when you’re not as familiar with it Extraction/componentizationTaking functionality from a method and creating its own method so that it becomes reusable to other functions Segment 2 - Tips Refactor often Create a refactor listWhen you notice a code smell but need to focus on functionality, jot it down in a refactor to do list so you don’t forget to go back and correct Change obscure variable names to proper named variables (Maintainability)Also use appropriate variable types. In JS we are limited but we still have the choice between let, const, var When you notice you’re using the same of similar functionality in multiple functions, externalize that functionality into its own function (extraction/componentization)That could be a seperate function, or it can be a seperate file with a it’s own class and extensible functionalities In vuejs currently you can used Mixins which allow the use of methods across components (in the future this will be handled with hooks) Remove old code that you previously commented out Clean up unused files, folders, functions and images Change code to be extensible to your needs (Extensibility)During sprints with short deadlines sometimes you’ll write code to just get something working while realizing that certain functionality that needs to be implemented in the future won’t work with the current implementation Example: Internationalization Remove unused librariesWe all add libraries as we code to try to meet deadlines faster, but sometimes they don’t work the way we want and we move on to the next one. It’s important to remove them when we realise they don’t fit Use tools like prettier and lint to help maintain code structure on a daily basisExample making sure everything is in spaces instead of tabs Arrow functions instead of expression functions Add comments to sections of code you think need explanation (maintainability) Web News - Work/Life Balance One of the disadvantages of being a contractor/freelancer is not having that 9-5 work structure that you have to follow Depending on your situation though it might be an advantage, if your wife works from home also, you can sometimes spend the best parts of the day together. Instead of going shopping at peak times you can go earlier and just work when you get back Take advantage of off hours for traffic A structured day is great, but everyone has a different work rhythm and being able to structure your day based on that can greatly increase productivity. If you work better in the mornings and early evenings you can make the middle of the day your time off for instance If your considering freelancing you have to be able to structure your own days, which seems simple but can really be a challenge. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit

In this episode we take a look at taking on complex tasks in a field where you're not very experienced, something all programmers must do at one point or another in their career. Segment 1 - The Newcomer Effect This segment is going to focus on our experience configuring a vuejs service worker - I went in with no previous hand-on experience, a complete newcomer to service workers and an amateur at vuejs. Therefore this process is no doubt clunky, but as you’ll hear that’s exactly the point I want to be clear before I dive in here that we’re using the following particular scenario because it was recent, we are not pointing the finger at any of the plugins, apps, or resources that we mention below. The issues we’re discussing are industry-wide, and not on a specific service, platform, or individual. Recently we went to work with service workers on a Vue.js app (No BS News for Reddit) As apart of the coding challenge we had already had a basic service worker setup that allowed the local assets to load when the app was offline This functionality was made using a pwa plugin for vuejs We left this plugin mostly, if not completely, in its default configuration This default configuration registers a service worker and then generates a service worker file which caches those offline assets Mike got the project to this point during the coding challenge and then I took over This is where things all fell apart for me: I had done a couple of days on reading basic service worker configurations and functionality and then finally decided to dive into our project First thing I did was look around the file structure and I find a file named registerServiceWorker.js This file contained an import line regarding register-service-worker (which fueled my initial Google searches) as well as the registration and basic responses that you’d expect such as successfully registered, detecting offline, etc. Searching register-service-worker led me to the page that I linked above, which had some very brief documentation and a code example that looked like our registerServiceWorker.js file (so far so good) From there I ran some tests in Chrome, checking for service worker install, checking offline mode, etc to get my bearings At that point I wanted to start adding some code of my own to the service worker, from my readings I knew that the service worker was definitely a separate file and from the registerServiceWorker.js file I could see that it was referring to a file called service-worker.js Searching the directory for said file revealed that it didn’t exist I then went and checked in the browser again, taking a look at the sources tab to find out what file was running the service worker, it showed that it was definitely service-worker.js - which indicated that the file was being created dynamically as apart of the build process This led us down a rabbit hole of finding how to inject my service worker code into this autogenerated file Overall, we eventually did find a solution for the code injection, however, it was not in the original register-service-worker documentation, nor was it discussed a lot on stack overflow We did find one Stack Overflow thread that did help, which led us to a useful blog and a couple of interesting links - I also found a separate page on npmjs.com somewhere along the lines which contained the missing code we were looking for Basically we needed to add some injection configuration into the vue.config.js file and then from there make our service worker script Now I know that’s long winded, but it points out some very important problems/concerns: The newcomer effect is alive and well, I wrote an article on Medium about what I call the newcomer effect a long time ago, it basically means that any documents/signs/directions that are available for any given experience rarely take into account the needs of those that are complete beginners - increasing the entry “budget” for newbies I’m not sure how documentation writers do it - maybe it’s because they’ve been working on their projects for so long - that they completely miss major steps in their documentation. It’s got to be mentioned that we desperately need better documentation for beginners and furthermore, more linking between potentially helpful guides In this particular case, maybe it’s because many folks won’t write their own service worker, but rather just want the default to cache the local assets and that’s it, but shouldn’t it at least be mentioned that if you want to write your own service worker - please see x Toxicity and useless comments are alive and well - on various forum posts, comments, and of course Stack Overflow posts there are typically an abundance of comments that dismiss questions due to “user not being experienced enough” or similar reasons. Or questions that are marked as duplicates, when really the question was indeed unique enough to be answered I want to be reiterate here, that I’m simply mentioning some of the roadblocks that we face wh

In this episode we sit down with leadership expert Scott McCarthy, to discuss leadership skills related to small business and independent entrepreneurs. Segment 1 - Introduce Yourself Segment 2 - Starting Out Do you think that leadership is more of a school-learned skill (note-taking, reading, etc.) or more of one that you learn by putting it into practice? How closely would you relate self-discipline with leadership skills? Should you work on self-discipline before trying to lead others? When entrepreneurs are first starting out, they’re generally alone, or with a small group of other company founders. This leaves them partially or completely isolated from leading other people, a skill they would need to develop should their company grow and hire employees down the road. What advice would you give to someone looking to up their leadership game, before they hire employees? A common mentality for new entrepreneurs is to just dive in and figure things out when you get there, which could lead your business into disaster. What’s your opinion on this mentality? Should people prepare more before they dive in? How tied up should leaders get in the details? Should staff worry about details and leaders focus more on the big picture? (ie setting a sales goal without having the intricate details of how to reach it) Many people that are thinking of starting a business are looking to stash some money away from their day jobs so that they can slowly lower their hours to work on their business idea. Given that their day job is a different experience from their would-be business, how would these entrepreneurs transfer any leadership skills they’re learning on the daily, to their new business? Segment 3 - Types of Leader One of the things that I struggle with a lot, is trying to determine what kind of leader I want to be. I want to maximize my team’s output, but that the same time, I don’t want to be a “force to be reckoned with” when entering the office. I often flip between being a ruthless money-only kind of leader, a laid back “tech culture” leader, or something in between. Does this kind of decision naturally work itself out as you gain more management experience, or is it more dictated by the stage of the company? (ie only the richer companies can afford to be laid back) How much, if at all, does the job dictate the type of leader needed? Should leaders have “modes” that they snap into in certain situations? (ie Be really monetarily aggressive during an economic downturn, and lighten up when the business improves) Web News - Difficult Situations When faced with a difficult situation, having a strong leader is critical to guide the team through the storm. This is easier said than done, however, because there are so many aspects of a business that a leader has to keep in mind Things like: employees, asset management, capital, revenue, expenses, etc. In an example scenario, let’s say that there is a struggling app development business that has 1 boss and 5 employees. The business is struggling to find customers and therefore can’t afford to pay their staff’s wages for any more than a couple of months.The company does have some valuable assets in the form of useful apps that could be put up for sale to raise capital. In this situation... How critical is employee loyalty? Should layoffs be step 1? Should assets be sold off before layoffs are considered? If layoffs are inevitable, how do leaders soften the blow? Or do they just move on? What is the main goal the leader should push for? (ie keeping the people employed, maximizing profit, liquidating to gain capital for themselves, retaining assets, etc.) Scott's Links Website w/ Social Links https://movingforwardleadership.com Facebook Group https://movingforwardleadership.com/mastermind Free eBook Preview of "The 9 Foundations of Leadership" https://movingforwardleadership.com/download Email Scott for a free 15 minute coaching call [email protected] You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit

With Vue.js' popularity steadily rising, many of you are probably thinking of migrating from jQuery. Segment 1 - State of jQuery https://jquery.com/ jQuery is a javascript library mainly targeted at HTML document traversal and manipulation, event handling, animation* and ajax requests. Meant to simplify your code and reduce the amount you would have to write doing simple things such as Assigning event listeners to all elements of the same class Creating DOM elements such as DIVs Using the $.ajax shorthand to interact with API’s/server calls So main theoretical advantages areCode becomes easier to read You write less code Familiarity, lots of developers have used jQuery for years and can write it without looking at documentation. Switching from something you are extremely familiar with can be a tough and costly venture jQuery has now been around for over a decade (since 2006) and as with everything in our field, it has started to be seen as ‘ancient’ technology. I wouldn’t agree with that kind of labeling but having used jQuery for the better part of my web development career it does have some pitfalls Transitions and animation rendering isn’t well optimized and can lag Large transversal are often bulky and execution time lags in comparison to native Javascript solutions Javascript api’s have improved over the past decade to the point where it is easier to implement and has more features then a jquery solution With the emergence of large javascript frameworks like React and Vue.js jquery has lost some ground as integrating with these frameworks, although possible, is usually viewed as resource costly and redundant Segment 2 - From jQuery to Vue As with anything new, it will take some time to adapt to a new way of developing when going from your typical jQuery workflow to a more framework based Vue.js workflow There are key differences with how jQuery handles things vs the way Vue does. Examples of those differences: Assigning a function to DOM element such as a div or a button In jQuery assigning a function is done in the script tag by using the $(‘.class or #id) selector and then extending it with a .click/.change(function(){dosomething;}) In Vue a dom/template element is tied to a method that is created in the vue instance. You can assign them to any event weather it be a click event or a change event using the @click, @change syntax on the dom element Transitions/Animations jQuery has plenty of . extenders that handle simple transitions like fading in and out (.fadeIn .fadeOut) and most other simple animations. They can be activated within your js scripts on any element using the typical $ selectors. These do not use css animations or transitions and have notably worse performance then them Vue has a tag that can then be tied to a css animation or transition. The transition can be activated on any state change, such as a simple v-if show hide Adding and removing classes conditionally/programmatically from DOM elements jQuery can do this by using the $ selector to get all elements of a particular class, or just a single element with an ID. It can then using the .addClass or .removeClass extension to do either function In Vue.js you have to bind classes to each element using the : notation. So on each element you need a conditional class, like a active class for a button, you assign the :class with a condition. Like active : isActive which binds the ‘active’ class to the isActive data property/variable. So anytime isActive is set to true, the element will gain the active class There are many other differences, like Ajax requests, which are handled by the axios library in vuejs and dynamic DOM element creation which is a major feature of Vuejs but is considerably more janky using jQuery. In the end making the transition from jQuery to Vue was quite hands on and involved a significant amount of adapting and learning new skills. Not to say it was overly difficult, as we’ve been saying many times in this podcast, having a good base knowledge of pure Javascript makes it easier to pick up new technologies and switch between libraries and frameworks. My advice for developers just starting out would be to still get a good grasp of native javascript and then jump into a framework like Vue.js or React. With native javascript getting most of the features of jQuery, it doesn’t make sense for a developer to invest their time into learning it. Useful Resource - Meta Tags https://metatags.io/ MetaTags.io can help you investigate existing, modify, or create meta tags for your website, across multiple platforms You’re able to type in a URL, which will pull in all the detected meta tags such as a photo, the title, and the description From there you’re able to see exactly what your metadata will look like in Google as well as other popular services such as: Facebook, Twitter, Linkedin, Pinterest, and Slack If there’s something you need to add or change, you can do that right on the web page. When you’re done, simply click on

Pivoting a project can be a blessing, or a curse. It's important to know when and when not to pivot to avoid derailing your development cycle. Segment 1 - Our Pivots When first starting out it’s important to be open to all avenues to you In our case we chose to try to get into the IT and Web Design/Development business from the get go. Although we did have a few IT clients we both seemed to prefer the web development side of the business as time went on. Eventually we landed a larger Web development account and at the same time had an opportunity to take on a medium size IT contract for a medical clinic. This was when we had to decide to go fully into web development or try to keep up both sides. It seemed like if we tried to keep both sides our preferable side would suffer so we chose to Pivot fully into web development Recently we decided on another Pivot Our choices were continuing trying to expand our service industry and get more clients for a steadier income or try to build a audience and get more in touch with the developer community in an attempt to eventually generate a more ‘passive’ income source Of course if you’re listening to this podcast you know the route we chose, as HTML all the Things is our way of connecting with all of you This wasn’t an easy decision as the temptation of more stable income was high. I was engaged at the time (married now) and obviously with that was a little worried to dump a bunch of potential income for a chance at building a community When we didn’t pivot Situations will constantly arise in your life, especially if you are trying to make your own path, that will tempt you to Pivot what you are doing Sometimes you will pivot, and sometimes it’s better to stick to your guns and forge ahead An example a time a we didn’t pivot was when we were coming up with project ideas and after launching our first html5 based game (Click to Riches) we wanted to create more games and almost become a html5 based gaming studio. This sounded really fun and we had a blast making Clicks to Riches but looking at it analytically the competition was extremely high and to generate any sort of consistent profit would have potentially taken years. Segment 2 - Pivoting a Project Generally when you’re first coming up with a project, you’ll list all the ideas, features, and systems that will be included either at release, or down the road These features should be categorized into various groups, some of the common ones are: MVP - all the vital features that are needed to make the project function/solve the problem it’s out to solve First Updates - Some features that are close-to-vital or easy to implement and will be added to the project soon after release Wishlist - Features that would be “cool” to have in the project, but aren’t vital to it’s core functionality Pivoting a project is not a decision to be taken lightly Whenever you pivot a project’s direction, it almost always adds a bunch more work to the original plan, typically some of those wishlist features are bubbled up to the MVP, or first updates category Pivoting at any stage of a project can have some terrible results: At the beginning - You might end up pivoting before or during the first days of development, which throws off the entire plan and can render any work done so far as completely useless Later on - Pivoting when a bunch of the work is completed can completely disrupt the development procedure and can ultimately derail a development cycle. For example, QA might not be able to test everything they want to because some of the features they were planning to test are now going to be radically changed. In addition, pivoting later into development often can result in added features that will be undercooked in the release, and therefore can produce a less quality product On the flip side, sometimes pivoting can have some great results: Better product that is more fitted to the marketplace More features that were initially thought to be useless, but ended up being vital in some way Matching, or beating, a competitors offering where the original MVP wasn’t capable of doing so Ultimately, pivoting is something that will come up on many projects, but you should be resistant to it Ensure that the reasons for pivoting far outweigh the reasons for keeping the project the way it is There is great value in sticking to a plan because people get familiar with it, and know what to expect. Changing said plan can result in chaos for the development team We slightly pivoted No BS News due to Google Play’s new PWA application system that allows for PWAs to more easily be put onto the Google Play store. As a result of this change, we decided it best to have some offline features and to tie up any lose ends. The benefits of pivoting No BS News in this way are: Better exposure and marketing on Google Play (discovery engine) More functionality will be added that will make it function more like a real app that relies on the internet, but caches some of

In this episode we talk about keeping our projects together with OneDrive and eventually upgrading to git for full version control. Segment 1 - Starting Without Git We used to use OneDrive to keep each other on the same page We had the same OneDrive directory sync to our computers so that our work would carry over However, this is not proper version control and therefore a bunch of conflicts would happen if we were working on the same projects, luckily most were minor and just required someone save their work again This solution did work for us, however, and we used it for well over a year with only a few major sync issues - which is pretty good for a program that’s not meant for version control To this day we still use OneDrive to keep some common files around, like graphical assets, however, our projects are not housed there anymore Our experience with using OneDrive rather than a proper version control did show us that it is possible to get started working as a team, even without the “industry standard” tools (in this case git) This is especially true if you work on projects yourself, or don’t touch any of the same files as another developer, so you can still have reliable file access across various computers while you learn how to use git Segment 2 - Transition to Git Working on your own is still a good time to learn and practice your Git skills. Even though it might seem like it’s slowing you down it really is just preparing you for the eventuality of working in a team environment and is something that is definitely going to come up during interviews and jobs Learn the basics first Cloning - initial act of taking the repository from your git source to your local computer Pulling - taking the changes from the remote (git source) repository is updating your local repository Committing - This is an action that ties the current changes you’ve made in your local repository to a ‘commit’ object that you are able to label/message with references to the changes you’ve made Pushing - Taking all your local commits and transferring them (pushing them) to the git source repository Fetching - Updating your local git file with the current updates that are on the git repository (origin) Branches - A system where you can create ‘branches’ that are essentially copies of your repository. This allows you to develop code ‘risk-free’ without touching what is referred to as ‘master’ (master-copy). Usually branches are used for feature development, and best practice is to create a branch for each feature and once that feature i complete to close that branch Merges - This is a system in place to handle taking your current branch and merging it into another one (usually a master copy or a pre-defined integration branch). The trick here is to avoid working on the same portions of code in different branches as the merge will create a conflict that you will have to manually resolve These base core concepts make up most of the functionality you’ll need to know to at least have a good base and be able to integrate easily into any companies workflow Sometimes learning specific workflow habits (like we’ll cover in segment 3) can pigeon hole you as almost every company has a different workflow and if you don’t understand the basic concepts it’ll be tougher to go from one workflow to another Segment 3 - Workflow and Benefits Recently we’ve begun working in larger teams and that has pushed us to develop a Workflow This is just going to be a example of the one we developed. Other companies will use different approaches depending on project complexity, team size, technologies available, etc. Our branch structure is as follow: No one codes in master, it is the production branch and only once the application is fully tested do we promote to master The main development branch is called dev-integration Here is where everyone's feature and design branches will merge into for testing Every developer gets their own branch, usually just one at a time although there are a few exceptions if multiple large features are being worked on at once. Once a developer feels like they have a good section of their feature is done and ready for testing they will create a pull request A pull request is a system within gits infrastructure to signify the attempt to merge branches Usually it’s easier to use your git service (bit bucket, github, gitlab) as they have a UI designed for this feature It allows the team to view all the changes that will take place during the merge, and gives them a chance to provide feedback in a thread style format Once approved, the lead developer can initiate the merge A developer does not need to initiate a pull request to merge dev-integration into their local branch as there are no consequences of that, they can just a do a git pull origin [branch name] Pull requests also provide a good history on your project, as long as the team names their requests appropriately you can look back easily to when a feature when merged in Like I m

In this episode we discuss website builders in general, then do a deep dive into Webflow. Segment 1 - Site Builders There are many reasons out there to use a site builder, they can range anywhere from convenience aspects, to pricing. I think it’s fairly important for a web developer to be at least familiar with these reasons and also the downfalls of site builders so that when it comes time for them to explain to their customer why they need a custom website, they will be coming at if from a place of knowledge and truth First thing to get out of the way, some customers will actually benefit from a site builder over a custom website. People that can find a good template on a popular site builder that fits all* their needs right off the bat People that like to tinker but don’t have the time to learn a whole new skill like web development Someone just starting off with a bootstrap budget and a ton of time on their hands for their business If you ever run into these people and they ask for advice on what they should do in terms of hiring a web design firm or doing it themselves, and they meet any of the specific categories above, you should definitely not hesitate to offer advice on using a site builder. Being honest with potential customers is key to earning trust, and maybe now they won’t be paying for your service but they will remember your advice and honesty when it comes time to update their site in the future Now with that out of the way, with a lot of clients a site builder just won’t cut it. If a client brings up a site builder and shows you a template they found and like but then immediately says they want to change x, y, and z. That is a red flag that a site builder just won’t work for them. Changing anything on a site builder can be a huge hassle (sometimes possible) but a lot of the time will require some knowledge in web development anyway. If security is a huge concern some site builders should be avoided. We’ve had many issues with multiple clients getting hit at the same time with WordPress hacks. The disadvantage of using a large platform like some site builders is that if a hacker finds a way into one site, they find a way into all sites. Shopify seems to be a fairly safe alternative for ecommerce as they treat security as a extremely high priority. If the client doesn’t have the time to completely manage their entire website If they need something very specific like integration into their customer database or their item database. If your customer thinks their business will grow quickly. Site builders are usually not designed to take on a huge influx of visitors and can have serious performance issues when that happens. This leads us to something that can be seen a happy medium between a traditional site builder that usually a client would manage, and a custom website/cms that a developer manages. Webflow is kind of a site builder for the web developer. It does require knowledge in css and layouts but is also very visual. If you have a client that you think would like to sit down with you while doing some design changes, or A B testing, webflow allows for easy live manipulation of design and can be a good tool for something like that. Segment 2 - Webflow Overview Webflow Designer The Webflow designer is the tool that is used to create the website itself. It has the more advanced tools that allow a developer to “code visually” meaning that the majority of the controls they’re using are actual CSS properties that they would be typing in manually For example, if you want to use flexbox on a particular section of your website, and have those flex items centered horizontally. You would add a div for the flex container, add divs for your flex items then with the UI actually set the display property to “flex” and then set your alignment. Instead of typing in CSS properties you’d be toggling the identical options in the Webflow UI You have a lot of other standard CSS controls as well including things like: Classes & “Combo Classes” Width, max-width, min-width, height, max-height, min-height Padding Float and clear Overflow Position Typography & Fonts: family, font-weight, color, size, text decorations Borders Transitions etc. Because this is an editor there are a bunch of non-standard CSS elements that you can add to your pages as well such as Containers that keep your content within a centered not full-width container, or social media widgets that have you entering in your username, or profile URL to setup a “like” or “follow” button Symbols are a piece of a website that you use over and over on a website. Things like a navbar, footer, sidebar, or widget of some kind all make for great symbols Symbols allow you to just add them to a page with a couple clicks without having to copy+paste, or remake them in any way Although I’m only now just starting to use this feature, a lot of the Webflow community seem to really enjoy what Webflow calls Interactions, which allows you to chain together events to cr

In this episode Mike and Matt discuss what it's like to take on your first website contract as a complete beginner web developer, focusing on a small business website refresh. Segment 1 - Gathering Requirements We’ve talked about requirements a few times but this whole conversation will be very specific to a typical first site that a developer will have to do for their first project. So in this scenario a small business call Happy Coffee has approached you with a request for their old site to be updated. The site is from the early 2000 and is very old, not responsive and has outdated information about their business. They would like you to update their online presence with the new web standards and make their site look more modern. Your job here is to figure out what the clients preferences are and if they align with your vision for the new site Ask them to send you some sites of the their competitors they like and to highlight the specific sections that appeal to them Ask them about specific features that you know are common to these kinds of ‘business card/online presence’ type sites. Contact forms Large cover images Services offered Map of the location Hours of operation Small “Our Story” section Photo Gallery It’s also important to gauge if they have content for you or if you will need to generate content yourself, whether that is images or text. This will give you a great starting point for either creating a static site from scratch or choosing a template to fill in and adjust Now usually during the more general portion of this process you’ll also be discussing pricing but I’m going to intentionally leave that part out as it’s a whole other can of worms and can be discussed in a separate episode. But usually for a first project, my advice is to be reasonable with your pricing, don’t do it for free but know that this is a stepping stone and the client is taking as much of a risk on you as you are sacrificing price wise for the client. Segment 2 - Design and Iteration Generally when someone wants a basic website, especially when it’s a small business, they’ll want to keep the budget low, cutting down on hours is probably one of the easiest ways to lower the price for a customer, having a basic design allows you to cut down some hours while maintaining quality Often times on larger websites clients will want a wireframe, as well as a prototype, or a fully done-up visual design before they’ll approve the look and you can start coding When it comes to smaller projects we’ll generally skip a lot of the designing procedure and rely solely on wireframes for a visual aid As a brief aside, even some of our larger customers accept wireframes as the basis of their design in order to keep costs down and get the project up and running as quickly as possible Typically we’ll make 3-4 different wireframe layouts based on what the customer has requested, often times we’ll get a few reference sites (as Mike mentioned) from them during the gathering requirements stage of our interaction to speed up our wireframe creation After showing off the various wireframe designs, we’ll get the client to choose their favourite one, get general feedback if they’re not happy with any of them, or get them to mix-and-match pieces of the wireframes together (slider from design 1, footer from design 3, etc.) This part of the procedure can take anywhere from a few hours, to over a week depending on how involved your client would like to be in the design - sometimes the design will flip-flop between a few options before finally landing on the one that will be put into production, so this step requires patience One thing of note, all clients are different, but from our experience if you’re struggling with the basics of choosing one of the designs that you made (ie the client doesn’t like any of them) sometimes you need to have a discussion with them to reiterate what their goals are to ensure that you’re on the same page (ie you might be focusing on showing off their photos, while they just want people to see the phone number and call the office) Luckily with simple designs the selection procedure is often the least painful and you’ll be off to the development stage in no time Segment 3 - Development Since this is a simple static site development is fairly straight forward There are a few choices you will be faced with Go with a template Create a static site from scratch If time allows I would recommend creating a site from scratch as you will learn the basics a lot better, and give yourself a better understanding of CSS, HTML and JS The workflow I do when creating a site is I first create a skeleton file structure with the typical css and js and img folders. Depending on how you were taught you can either do this manually or with webpack and babel. I’ll focus more on just a simple file structure now but don’t be afraid to use the tools you were taught if you are comfortable with them. When creating the folder structure create all the necessa

In this episode we discuss the difficult conversations we all face when dealing with customers including pricing, misunderstandings, and more. Segment 1 - Saying No Sometimes customers relations aren’t just selling them on your latest theme, service, or skill - there comes a time where you have to deal with intricacies that have a negative connotation attached to them Specifically these are often: pricing, value (of work and of the product to the customer), bad content (low quality images, bad copy, etc.) - essentially you’re saving them from themselves, their web presence should start out on the right foot when you’re done with it Pricing Pricing is almost always a major point of contention between you and your customer People always want a lower price, and they’ll try anything to get it The issue with you constantly lowering your price is that even if you don’t intentionally do this, you will have a lesser quality product because your motivation to complete it will drop. Scope creep (customers adding features onto the original scope of the project) is especially bad when you’re doing a project and being underpaid - and the outcome will be of lesser quality You should go into a pricing meeting with a price range in your head, or one solid price if you aren’t willing to negotiate, and stick to the plan. If the customer is unwilling to pay a price that you’re okay with, then you just have to back out politely (this isn’t gonna work, thanks for your time) When it comes to older businesses, or specifically ones that don’t run off the internet, they have issues paying for online services like web development because their business doesn’t generally value the web too much Value Value and pricing go hand-in-hand, everyone wants what they paid for and preferably a low price on a high value Sell customers on the value of your work can be difficult depending on how much they rely on their website For example, if a company if almost completely reliant on their eCommerce site then upgrading it - even for a high price - may be something they’re willing to do to ensure the revenue keeps flowing On the flip side, if you are working with a customer that simply has an online presence, like a basic website with a phone number - they’ll generally generate their customer via other means (newspapers, word of mouth, billboards, etc.) and therefore will value their online presence less. When you have a customer that doesn’t value your services much, often times the project will be less complex, however, they won’t offer you a fair dollar for it because it doesn’t generate them enough business to pay for itself over the short term. Sometimes a customer is looking to become more active online, which is why you were contacted, but they still don’t know the value of a good online presence, what it takes to generate traffic, how to manage social media, etc. In this case it can be very difficult to get a customer on-board with a price that you’re good with, versus the amount of work he wants done to become relevant online because they don’t understand the value of the work you’ll be doing for them Bad Content We’ve all been there, you’ve been hired to look at an old website that was designed for old SD monitors, you come up with a plan to revitalize it which results in a list of photos and other content that you require the customer send to you (ie staff photos, office photos, staff bios, etc.) and they just say to use the old ones because they look good This is one of the hardest things to convince people to change, they’re attached to the old photos and text that they wrote years ago, but those small SD photos just aren’t equipped to handle the HD screens of today and will look awful It’s your job, as unfortunate as it is, to politely push back on customers explaining to them that if they’re refreshing their site, they can’t have old assets on there or else it will look awful. You need to try and convince them to update everything to modern standards and to ensure that any copy is up-to-date In order to do this try and tell them that their customers will take notice that their site looks messy, or slapped together for cheap which will leave them with a bad first impression. You can also offer to make some of the content for them, if you’re willing and able to, for a price of course. Ultimately it's your job to ensure that their web presence gets off on the right foot when you’re done with the project, ensure that things are as high of quality as you can. Segment 2 - Aggressive Interactions Handling a client that is angry can be a challenge There are a few strategies that we use to to handle these situations when they arise Let the client say their piece fully without interrupting them because if they are angry it’s important to figure out why before you can diffuse the situation Once they seem to be done try to show empathy and don’t deflect their problem back at them. Even if it’s fully their fault take some time to think of it fro

In this episode we share some of our tips and tricks that we've picked up along our many web development and design adventures. Segment 1 - Matt’s Tips & Tricks Server/Hosting Management Common things like this include: WordPress updates (plugin updates), migrating to a different server/host, testing a new major feature, adding something a client has requested - but you think won’t work out which will result in a rollback Always backup files and databases that you won’t be able to get back in their existing state Be wary of new commands if you have command line access, especially if they’re aimed at deleting files, or folders Have a recovery plan before you begin so that you can quickly and easily rollback your changes if something goes terribly wrong - planning this out properly may require you to take full backups, prepare a re-upload solution, research re-installation information on some of the software you’re using Have a testing environment setup that mimics your production environment preferably CSS Don’t be afraid of simply setting up a skeleton before moving onto a different part of the site - having a skeleton of the top bar while branding is being figured out is a good way to get started on the site, and frees you up to spend more time on other elements that are more definitive (ie slider, contact form, etc.) Make your class names easily identifiable, whether you use a naming convention or not, at the very least use something that you’ll be able to identify later and that other developers would be able to pickup on if they interact with your project in the future (example classnames: navbar, nav-item, footer, topbar) Comments (and this goes for other languages to) should be done to clarify things for yourself in the future, or for other developers down the road, however, sometimes you understand something using references in your own head - do not hesitate to make comments specific to you if you’re actively working on the project, using references that only you understand - making the comments more generic for others when production hits Test responsivity with true window widths, not just responsive tools, sometimes these tools don’t reflect exactly how different browser window widths will actually react which can result in some overflow left-to-right or some broken elements altogether Segment 2 - Mikes Tips and Tricks (JS Tips) Use a scope variable If you’re using just straight javascript for a single page or multipage website create a scope global variable. Make sure that this is your only global variable for the whole project but if you need to pass state or variables between files or pages then use only scope to keep some form of structure and minimize conflicts Use libraries when necessary Make sure it has been updated in the past year at least Make sure the documentation is fairly easy to understand Check the Open issues tab in github and make sure that there are plenty of closed issues and check those closed issues to make sure you are fine with the answers given as if you have an issue you will have a similar experience When working on a large project there will be times when you’ve gotta complete features under a time limit. This is where libraries can really save you a huge amount of time and headache. I recently had to create a searchable list for an application with the ability to auto filter the visible list as you type. Even though this is definitely something I could have created from scratch I didn’t want to waste my clients time if that is unnecessary. Doing a quick google search yielded plenty of well maintained, small and feature rich libraries. One called list.js really exceeded my expectations. Here are some tips for checking if a library is worth using: Do your best to write self documenting code with comments being used only when necessary I am very deliberate in my function and variable names to make it easy to go back to my code and understand what is going on If a function is calculating the taxes on the order then call that function calculateTax() Try to avoid using ternary operators (condition ? true expression : false expression) in code that will need to be maintained by multiple people over long periods of time. As ‘professional’ as they make you look they are not easier to understand then a simple if statement. Nor do they impact performance in any way Refactor and clean up code often With larger projects code can get out of hand really fast. If you’re programming at speed and do a lot of testing where you comment out sections and write new ones to see differences those commented out sections can add up and can contribute to confusion and maintainability in the future Sometimes you can preemptively create variables and functions and then never use them going forward. These are just taking up space in memory and adding even more complexity to your code for no reason. These are prime candidates for removal in a refactor Chrome Dev tools are your friend These are a hug

In this episode we discuss our recently completed coding challenge, making "No BS News for Reddit" Note: We had some audio issues with the first upload of this episode, if you hear nothing, simply delete your version and re-download to get the updated file. Apologies for the inconvenience. Segment 1 - Pre-Planning & Design As apart of this challenge we were allowed to plan, design, and research before the challenge began To prepare we did some research on PWAs and their functionality We also researched other news apps, and what subreddits would be the most useful From a UX perspective, we took a look at which features a Reddit user would need and expect from a Reddit app - minus the social features of course From this we came up with some wireframes to guide our design throughout the process, which we modified on the spot to accomodate for a “open Reddit post” button alongside alternative share options for PC users We also had a discussion regarding the addition of custom news sets, where users could select a bunch of subreddits to pull into a single custom feed - this ended up using up a decent amount of time and we didn’t put it into the app in its current state One other design challenge that we had was making the design pop Since this sort of app is so text-heavy we were concerned that its monotone nature would end up making it boring, or otherwise, look unfinished and rushed. However, after spending more time on Reddit we realized that this type of app is more utilitarian than it is flashy, so we decided to place it in a dark theme and let the links “do the talking” Segment 2 - App Development Development went smoothly for the most part We were able to complete almost all the features that we originally set out to make, including a few extra ones We had a few bugs popup that were dealt with quickly, namely some responsivity issues with overlapping and some time stamps that were coming in as negative numbers Vuejs seemed to almost accelerate development due too it’s built in development server and its short code nature for functions and listeners Vuejs also created the template for the PWA functionality through the Vue CLI App functionality implementation went as planned and didn’t pose much difficulty other then a couple of hiccups and glitches that had to be fixed Showing how much time has elapsed since each post was posted showed to be kind of annoying because of how reddit handles UTC time. I have to multiple the time by 1000 to match with the the current UTC time Working with the reddit api is awesome and a great way to learn API’s and working with json The app is pretty much feature complete as in line with our MVP (minimum viable product) Couple of features we are looking to add would be : a way to create a custom news group Light theme to go along with the current dark one The motto for adding features to this is “Is that bullshit?” if we think it is, then we don’t add it Segment 3 - App Deployment So we’ve already had a few episodes where we talk about deployment in a little more detail but it’s valuable to mention how we went about doing this for the 24 hour challenge aspect This was by far the most frustrating part of the entire day as this would be only my second time deploying with Docker and to digital ocean It is simpler than the html all the things deployment because there is no server side containers but due to the time constraint and the fact we started deployment only at around 12am it turned into a problem The initial deployment as a web app went ok until we hit the SSL certification We used the same method as with HTML all the things, where we are trying to certify a docker container running nginx using certbot on our ubuntu digitalocean droplet Unfortunately I didn’t have a lot of experience and combined with already being mentally exhausted I went into a try everything approach instead of using logic Logically looking at it with a fresh head after getting some sleep got a solution in a matter of minutes Although this was frustrating this is all part of these short time challenges and must be overcome if anyone wants to be able to work in crunch periods Sometimes it’s important to step away, as I did that at least 2 or 3 times during the challenge to solve random issues For next time I think we might do a initial pre deployment before the challenge to at least get the ssl and nginx container worked out, so we have more time to focus on actually developing Web News - Personal Opinions on PWA Disclaimer: We have minimal experience with PWAs in both the development and consumer side of things, so these are simply our opinions having minimal exposure Progressive Web Apps fall into a strange segment of the market, because they’re not quite native apps, and not quite websites (at least under the hood) We’ve entered into a time where the internet is relied upon to power a lot of things and therefore an internet browser of some kind is almost always open on people’s computers, or phones On

In this tidbit episode we discuss our code challenge, announcing official dates, and other considerations that we've thought up over the past few weeks. We'll be calling our PWA (Progressive Web App) "No BS News for Reddit" and will be using: flexbox, Vue.js, and service workers to accomplish our task. The challenge will comprise of us trying to complete this app within a 24-hour period. As a PWA, we will be running it on Digital Ocean for hosting, which will also be our finish line. More specifically our goal will be to develop the app to completion, and have a functioning product live on our hosting package. We plan on releasing this app on an app store, or two, however, this will not be apart of the challenge. In addition, any time-based approvals (ie if Adsense needs to approve to run ads on the site) will not be apart of the challenge. We will work around them the best we can to provide an app that people can use before the 24-hour window closes. Before the challenge begins we're allowing ourselves research and design, but no development on the app itself - that will be all saved for the code challenge window. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub Reddit

Happy New Year! 2019 has just kicked off, and so has another year of podcasts. In this episode we discuss maintaining your skills after long periods away from your desk. This is the perfect compliment to the recently completed holiday season as many of us are just now getting back to work. Segment 1 - Keeping Things in Practice Keep using the technology you deem valuable The main way I stay on top of my skills is seemingly an obvious answer. By using them This can be a little difficult though with so many technologies out there and as we’ve mentioned many times it’s easy to get overwhelmed with all the choice What I try to do is choose projects that will incorporate the technology I value Sometimes this requires convincing your employer and contractor to adopt something they are not familiar with. So it’s important to be knowledgeable of the positives and be very clear with the downsides right from the get go. Recently I’ve been proposing using Vue.js for some contract projects Keep up to date with updates As technology evolves it usually get a wider feature set and perspective of when to use it can change I try to stay on top of technologies such as node, Vue.js, react and read their change logs. If a new feature gets announced I try to figure out where I can use it and how to implement it (usually using the documentation). Even if I don’t implement it just by going through the exercise of figuring out how it works I retain a little bit of that knowledge and will more likely know to come back to it when a new project pops up. Segment 2 - Combating the Loss of Knowledge When you’re away from your desk for a long time, you’ll become rusty at your everyday tasks and may completely forget new things that you learned just before leaving Furthermore, there are often times that certain snippets of code are used a single time per project and therefore don’t stay fresh in our minds because we rarely see them It’s easy to stress over losing knowledge like this because we invested time in learning new skills and in a few short weeks they could be completely gone from our memory There are a variety of ways to combat this, but it’s not something to stress over as it’s just a natural procedure that our brains do that is out of our control Recording Snippets Programmers of all kinds, whether it be web developers, game devs, or even hobbyists all have some sort of snippets manager Often times these take the form of a snippets managing software, but it can be as simple as keeping old projects and files laying around in a folder somewhere One key component to generating snippets is that your code is modularized rather than proprietary for each application, meaning you want to code up functions that can be used over and over again - If you have an application that uses AJAX for example, there should be an AJAX function that you can pass arguments into, rather than AJAX being done somewhere inside of another multipurpose function Snippet managers are great when you code up something that you know you will use repeatedly, but rarely need to interact with directly Example 1: You make functions that access and interact with an API once, then you focus on making the application using the data that comes from that API Example 2: You make a collection of CSS buttons that you use on a variety of projects Personally, I use a bunch of old projects and files inside of a folder because I always think of the project I did something in, in the past, rather than the name of a generic function. However, I’d like to build up a snippet library in a formal piece of software There are a bunch of snippet managing software out there, I haven’t used any personally, but some of the ones that came up in a quick search include: Boostnote (https://boostnote.io/), Cacher (https://www.cacher.io/), and Bracket Snippets for Brackets (https://github.com/jrowny/brackets-snippets) Letting Selective Knowledge Go One of our programming teachers in college said that he would selectively let knowledge leave his brain once he had learned and implemented it Specifically he was referring to a driver that he had written for a microcontroller that we were using in his lab class. He said that he only needed to learn the information for certain parts of the driver once, implement the driver they way he wanted based on his new knowledge, then he forgot about that specific piece of information he learned because he had already gotten from it what he needed This might be a hard pill to swallow, especially since things take forever to learn when we’re new to them, but it’s a valid statement If you think about it, if you were working at a company as a Ruby on Rails developer and suddenly got changed to a different team that exclusively uses jQuery for their projects, you’re going to forget Ruby on Rails pretty quickly if you don’t keep your practice up on your own time I like to think of it as, I learned something to gain value in some way, expended that value to its fulles

In this episode Mike and Matt discuss motivation in it's many forms, and how it affects working on variety of projects. Segment 1 - Types of Motivation Different types of motivation range from the tinkerer all the way to the passionate Being in any of these camps generally dictates how much effort, and time, that you’ll put into a field that you’re checking out In terms of web development & design, having a different level of motivation will no doubt determine where you fall within the field - maybe you’ll make a single website for fun, or maybe pursue a career One thing of note, these classifications of motivation are from our own experiences and ideas, they aren’t some sort of “official” classification of any kind Passionate When you’re passionate about something you’ll typically take it more seriously and do in-depth research to learn new things This type of motivation may steer your career decisions, or help you set up a side hustle of some kind For the web field, this generally means you won’t be using your “local” website builder like Squarespace, but rather diving in head first to the code, determining what tools you’d like to use and how to use them efficiently “Forced” Sometimes you’re figuratively “forced” into a doing something due to outside pressures, such as financial situation, or availability of work When this happens you may take your work seriously, however, you’ll be taking it more seriously and efficiently than someone who wants to be there, because generally you’ll want to get in there and just get the work done Often times people get trapped into these types of situations due to the outside pressures never alleviating, or more that suddenly pile on, leaving you trying to find methods to get out of the field Bringing this into the web industry, sometimes people will be “forced” to do professional web work, either full time, or by being in an associated tech field that suddenly requires web work. Generally this type of work will be rushed in some way, having tasks done in the quickest way possible - often leaving a lesser quality product Hobbyist Hobbyists are people that like to do a variety of things, and get into them all the way, stopping just before getting professional. There are of course varying degrees of hobbyists, but generally, they could technically operate in the professional realm given a small amount of training Bringing this again to the web industry, hobbyists will generally not focus on one tool, language, or segment of the industry, but rather fan out and use a bunch of different tools ranging from site builders like Squarespace, then dabble in some code - getting a full range of experience to build some sites that they’re interested in, sometimes these lead to a side hustle if they’re successful Tinkerer Tinkerers are one step below hobbyists, and are generally just interested in a field in some remote way They’ll do a variety of “light duties” within their interest, things such as reading some material, or maybe dabbling slightly within the field itself, stopping well short of investing any sort of money, or serious time, into learning a given field When it comes to the web industry, these people often need a single website for something they’re working on, they’ll read up on different site builders online and then just use a template so they can get to work - this of this as more of a blogger that doesn’t want to deal with their website, but instead their work is their writing itself, so they familiarize themselves with the path of least resistance to get a website up and running and that’s it Segment 2 - What Motivates Us Pure Enjoyment for coding Creating something from scratch Looking at examples of other people's work and striving to achieve something similar Looking through sites and trying to find motivation for your work Having someone or a group request something that you could make Small amount of adrenalin from fixing difficult issues Being part of the coding community Having people reach out to you for help or opinion Keeping up/learning new technology Segment 3 - Motivation Blockers To many projects on the go making it difficult to focus on one Prioritize and use task management applications like Asana Running into a problem that takes several days to solve Take a step back from the problem and maybe try to complete a smaller easier task Difficult clients This is a tough one but try to understand where your client is coming from and if you can relate to their issues Programmers envy There will always be people that are better than you but also people that are still trying to catch up to your level. It is important to learn how to focus just on yourself Procrastination Just start something, start with smaller more accomplishable tasks and build up to the harder and longer ones. Links Dan Mace's Video: https://www.youtube.com/watch?v=dMTJRYmQkbc Joe Rogan's show with Derren Brown: https://www.youtube.com/watch?v=n_tpWrv76Q8 Web News - Scams Scams are beco