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

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

By Matt Lawrence and Mike KaranNewsTechnologyEducationHow ToTech News
Download on the App Store

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

  • Advanced Topics w/ Little Experience

    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 when we’re newbies on a given topic, I’m sure a bunch of these affect other people as well. I’m not pointing the finger at this particular PWA plugin, Stack Overflow, npmjs.com, or any other website. I’m simply using this particular recent scenario to point out common problems that could be ironed out for those of us that are inexperienced. These problems can be found across any programming language, and even outside of the programming world in some cases.
  • In conclusion, once we got the service worker file running, we were off the races. We ended up being able to cache all our Google Fonts thanks to a helpful guide and are well on our way to getting more offline functionality added in the app. Once we had everything put together, the PWA plugin works great. But I stand by my position that finding instructions on how to setup something in Vue (or any other framework, library, or whatever you're using) shouldn't be the challenging part. The challenging part here should be that we need to get offline functionality working via our service worker itself, not figuring out how a service worker is setup in this particular configuration
  •  

    Segment 2 - Strategies
    • Complicated issues and topics arise all the time during the the development of a project
  • They can range from concepts you haven't heard of like Binary Tree Searches or design patterns, advanced algorithms or even just complicated libraries/frameworks
  • Sometimes when taking on a task it might seem that there's just to many unknowns for you and you’re delving into a sea of advanced topics
  • I’m going to go through a couple ways I go about learning and implementing advanced topics.
  • I start by breaking them down into as many smaller topics as I can
  • For instance if the topic would be VueJs id break it down into
    • Setup dev environment
  • Create first hello world app
  • Test reactivity
  • Figure out navigation
  • Figure out state sharing
  • Learn about components
  • Etc
  • By breaking apart a complicated topic into smaller manageable topics it takes away the initial feeling of being lost and allows you to focus on one small easy to digest topic at a time
  • If the topic is something that's hard to breakdown, or you don’t even know where to start breaking it down, it’s a good idea to take a look at the documentation and see what they start with. Usually the documentation starts with the simpler topics and moves on to the advanced ones. Of course if it has poor documentation that's a whole other problem that as Matt previously stated.
  • Once the topic has been broken down to learn more about each section I would actually start coding almost right away. So as you’re learning about how to get a dev environment setup, actually set it up.
  • The more I’m actually applying what I’m learning the faster I’ll pick up the concepts and find their downfalls and issues
  • Speaking of issues advanced topics can also just be hard to debug issues. We’ve had an episode about troubleshooting so I won’t go to far into it but essentially your first key goal is to be able to easily reproduce the issue, after that using the chrome dev tools as your guide, you can put breakpoints everywhere you need to read the state of all the variables as you progress. This method usually
    • Diagnoses my issues quickly
  • And gives me a clearer path for a simple solution
  • If you run into a roadblock and don’t see a solution at all, step away from that issue for some time. Even just getting up going to do a small chore might jog your brain into thinking about it from a different angle
  • Sometimes you’ll run into issues figuring out seemingly simple features and you might have to use these strategies for them too
  • Here's something that recently happened to me where I had to use all these strategies to get past a seemingly simple feature addition
    • Get the best library to work in a basic way to my liking
  • If it works figure out why it isn’t working in my particular scenario
  • Reproduce the issue
  • Troubleshoot the library code to figure out what is stopping it from working
  • Fix the issue
    • Had to add a comparison slider to a vuejs application
  • A few libraries to choose from so thought it should be easy
  • Tried all of them and they all had varying issues
  • Issue arose here, had to figure a) should I use one of these libraries or build my own
  • Broke down the problem
  • During the process of fixing it, I had to step away a couple times and each time I found different ways
  • Web News - Thin Client Computing
    • With the announcement of Google’s new streaming game service Stadia it seems like a good time to have a quick look at the current state and the potential future of thin client computing
  • When referring to thin clients I mean a small, low power computer that essentially is used to remote connect to a offsite powerful one that provides greater performance then you can get with lightweight portable computers
  • In reference to Google’s new game streaming service a person can play AAA games using any device that is connected to the internet and runs chrome.
  • There's obvious advantages to this
    • Using cheap hardware to still perform complex tasks
  • Being able to access the same environment from any device without any sort of backups or syncing required
  • Some not so obvious advantages actually can come for developers
    • If large thin client powerhouses like google become really popular, a developer is now coding for a single set of hardware, as the actual thin client that the user has doesn’t matter
  • Imagine gaming developers not having to worry what video card their audience will have because everyone will just be using thin clients to connect to a large datacenter with the same hardware in each machine
  • The limitations are also pretty big right now. Network connection being the main one. The latency of your actions appearing on screen can be very distracting. If you click your mouse and only a second later something happens it makes working with the system very unpleasant.
  • But with the knowledge that networks are constantly improving, latency is also getting better and maybe there are ways to make it almost unnoticeable, can you see a future where thin computing explodes?
  • Links
    • Plugin Links
    • https://www.npmjs.com/package/register-service-worker
  • https://www.npmjs.com/package/@vue/cli-plugin-pwa/v/3.0.0-rc.1
  • Stack Overflow Thread
    • https://stackoverflow.com/questions/51214220/vue-cli-3-how-to-use-the-official-pwa-plugin-service-worker
  • Guide we used
    • https://levelup.gitconnected.com/vue-pwa-example-298a8ea953c9
  • The Newcomer Effect: A UX consideration (Medium article)
    • https://blog.endpointmedia.co/the-newcomer-effect-a-ux-consideration-39889b6db077

     

    You can find us on...

    Facebook | Twitter | Instagram

    RSS | Patreon | Spotify

    Medium | YouTube | GitHub 

    Reddit

     

    1 hr 20 min
  • Leadership w/ Scott McCarthy

    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

     

    You can find us on...

    Facebook | Twitter | Instagram

    RSS | Patreon | Spotify

    Medium | YouTube | GitHub 

    Reddit

    1 hr 35 min
  • jQuery to Vue.js

    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 are
    • Code 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 the “Generate Meta Tags” button and a new snippet of code containing your changes will be generated so you can paste them into your tags
  • Our use cases:
    • We’ve been using this a lot with Webflow recently
  • In Webflow you’re able to set site-wide meta tags, set static ones per page, dynamic ones based on CMS data, and even allow users to edit meta tags specifically via the Webflow CMS with some configuring
  • Because there are so many options affecting meta tags, checking out the metadata in metatags.io really helps us inspect if the dynamic data is working out, or if the customers are filling things out correctly.
  • It also lets us specifically test how metadata looks on all the customer’s preferred platforms all in one place (ie facebook, twitter)
  •  
    Web News - Laser Focus in a Scatterbrained Industry
    • If you work for a big company, or listen to business gurus, “laser focus” is a commonly used phrase that has essentially become a buzzword of sorts
  • It’s generally used to describe the need for a team to focus on something important, such as a new project that’s coming up, or meeting a very important deadline
  • Often times it is also used to describe the general direction of a business, especially if a business is new, or is evolving with the times. The administration will generally ask for the staff to remain “laser focused” on their new movement, or business strategy to ensure continued success
  • This laser focus is also applied to beginner entrepreneurs when discussing the prospect of success. Gurus will often talk up working in their preferred industry, then bring it back down to earth saying things like “this is not a get rich quick thing, you need to stay laser focused on your goal to succeed, there’s no other way around it”
  • At the end of the day being laser focused on a goal is sound advice, but when it comes to complex projects, that laser focused goal has to be more general and can easily still lead you down the path to distraction and eventual failure
  • The website industry is all over the place when it comes to almost every single aspect.
  • Prices are wildly different from agency to agency for the exact same product
  • Building out projects take several different skill sets, or investments into services that essentially act as outsourced contractors (ie developing the site yourself and getting an SEO specialist involved to optimize for Google search)
  • Sometimes businesses don’t have any branding ready at all, which results in the need for illustrators and other related artists to make up logos and colour schemes
  • Don’t forget about the fact that websites are always online, so when they go down, someone needs to support them, pulling your attention away from new projects that you have on the go
  • When you’re starting out by yourself, or in a small team, you’ll inevitably have to become a jack of all trades in order to keep everything running smoothly, especially when you don’t have the capital to hire individuals to run each aspect of the business individually
  • Herein like the question, how do you remain laser focused when the industry you’re in is so scatterbrained?
  • One possible solution might be to make the goal more general, but if the goal is just to make money, there’s way too many solutions to that problem that will hardly result in laser focus of any kind.
  • We suffer from this issue constantly, we’ll say something like “let’s just focus on money the next few months” and before you know if we have 3 app concepts, some marketing plans for client-work, and nothing actually done. Even No BS News was completed for the purposes of the code challenge, but then not published further than that because another possible money making opportunity came knocking.
  • How do you remain focused in the web development/design industry?
  •  

    You can find us on...

    Facebook | Twitter | Instagram

    RSS | Patreon | Spotify

    Medium | YouTube | GitHub 

    Reddit

    1 hr 9 min
  • Pivoting a Project

    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 the data it already has (minor offline functionality)
  • Is going to push us to finish the project
  • We need to learn service workers for some upcoming client work
  •  

    Segment 3 - Pivotal Paralysis w/ the Jack of all Trades
    • As we’ve mentioned in brief before, it’s often very difficult to stay focused within the tech industry given that there are so many positions and so much crossover between them
  • When you’re running a small business, or a startup, often times you need to wear multiple hats within the company in order to keep it afloat
  • These multiple hats result in experience and exposure to several segments of the tech industry, that provide useful skills, but also provide a bunch of distractions
  • Whenever you have experience in a given area, it’s hard to focus on the one you’re working on.
  • For example - if you’re working on making the UI for an app, and you have Photoshop experience, you may get distracted for an entire day on editing some icons that weren’t in the project’s original schedule. Resulting in a late and possibly rushed UI development
  • Distractions aren’t great for a project’s development, but these distractions can easily evolve into project pivots.
  • If you’re developing an application that focuses on calculations, but you have experience in graphic design, you might be distracted from the original goal of making a simple UI that allows the user to complete calculations. Instead, you might pivot the project such that it has a theming system and a bunch of cool UI elements that look nice, but introduce a bunch of graphical and UI work that will stall out development and isn’t vital to the project
  • Being constantly distracted by things you have knowledge of is a constant plague of the tech industry because so many people have a experience in at least a few segments
  • It’s important to keep to the plan whenever you can to avoid scheduling mishaps, missed deadlines
  • Personally, I find this jack of all trades w/ pivoting issue normally crops up in the earlier parts of a project because everything is still being flushed out and designed. It’s so easy to just flip a wishlist feature into the MVP that before you know it, you have a bloated app that will arrive late and might not be tested as much as you’d like because it had to be rushed to try and meet the deadline
  • Stick to the plan whenever possible, but keep in mind that the plan isn’t written in stone, just really close to it. Make the plan hard to change - pivoting is a blessing and curse
  • Web News - Community Moderation
    • With the newest ‘Adpocalypse’ happening on YouTube due to all the ‘sexually illicit’ comments appearing on videos with underage kids in them, what does this mean for the future of platforms like YouTube or even the internet
  • From pretty much the beginning of the internet anytime a community has taken off it inevitably has pockets of illegal behavior in it.
  • Usually even thought he community does it’s best or at least something to monitor itself it gets blamed for its members doing something like this
    • In YouTube's case it not only effects YouTube/google but all the creators on it. Most of which have done nothing wrong
  • Community moderation is pretty much impossible without limiting/censoring the community itself and therefore changing the product you are putting forward
    • There are some small examples of good community moderation in my opinion, Reddit did a good job removing all of it’s child exploitation subreddits without destroying it’s community
  • The problem is not all websites or communities are as easily controlled as Reddit’s. And at some point we need to look at the problem as a whole
  • People will always find ways to post terrible/illegal content online. Who is it on to moderate this?
  • Once we go down the rabbit hole of severe moderation what will the internet look like?
  • If we are in the “wild west” of the internet days what civilized days are we approaching?
  •  

    You can find us on...

    Facebook | Twitter | Instagram

    RSS | Patreon | Spotify

    Medium | YouTube | GitHub 

    Reddit

    1 hr 9 min
  • Pivoting a Project
    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.
    1 hr 9 min
  • Git Workflow

    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 mentioned previously once everything is merged into dev-integration and thoroughly tested, a pull request can be opened into master. This will then be vetted by the senior developers/engineers on the project and merged, after which production deployment and dev ops can begin
  • This is of course just a snippet of the whole process and there is plenty of nuance that occurs, the more you work with git the more appreciation you have for it usually
  •  

    Useful Resource - API Marketplace
    • https://rapidapi.com/
  • A lot of the time app ideas require an external source of information or some sort of off-app computing in order to provide a useful service
  • For example, a video game collection app isn't going to contain all the video games that have and will come out, otherwise the app would be enormous in size
  • Instead when you search for a game to add to your collection, the app will call upon an API which will generally search a massive database of video games alongside other goodies like cover art, release dates, etc.
  • Often times when people come up with an idea for an app, they'll back down from making it because their idea requires a lot of specific information, or needs some sort of machine learning involved.
  • Luckily there are a ton of APIs out there that can usually help out with these types of needs, allowing developers to finish up their apps without filling in massive databases, and learning very complex things like machine learning
  • Today's resource is an API marketplace called RapidAPI
  • I found RapidAPI, or more specifically Mashape, when I stumbled upon a Hearthstone API that linked to it
  • MaShape was acquired by RapidAPI a few years ago, so that's the correlation between them in case you're familiar with the MaShape brand over the RapidAPI one
  • RapidAPI contains tons of APIs in their marketplace that range from movie databases, to facial recognition
  • Each API has their own page that contains a bunch of useful information such as: popularity, average latency over the past 30 days, average success rate over the past 30 days.
    • Plus more technical things such as how to access the API in a variety of methods like NodeJS, PHP, and more
  • It also tells you whether the app is free, freemium, paid, etc.
  • You can even test our the API right on the page
  •  
    Web News - Multi-Device Workflow
    • Working across different devices is getting easier and easier whether you’re using the Chrome Extension that was just mentioned, using one of the Microsoft Office apps with the Microsoft Launcher (quickly open from “recent activities” in the mobile versions of the Office apps), messaging people in something like WhatsApp across the phone and desktop, etc.
  • Does this workflow open up new opportunities for progressive web apps that are responsive
    • You could be working in a PWA on your PC and have your phone automatically sync with whatever you were working on, and open up right where you left off with just a tap
  • This sort of workflow also points towards a more unified OS future, whether that be with more integrations between OSs (ie Word on Mac), or actually consolidating different versions of operating systems (ChromeOS/Android)
  • Microsoft added a Chrome extension that allows Chrome to access the Windows timeline
  • With the use of the Microsoft launcher being able to pick up exactly where you left off on your comp is a major convenience
  •  

    You can find us on...

    Facebook | Twitter | Instagram

    RSS | Patreon | Spotify

    Medium | YouTube | GitHub 

    Reddit

    1 hr
  • Git Workflow
    In this episode we talk about keeping our projects together with OneDrive and eventually upgrading to git for full version control.
    1 hr

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

From the publisher's feed

HTML All The Things is a podcast for developers navigating the modern web industry.

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

The Joe Rogan Experience by Joe Rogan

The Joe Rogan Experience

227,535 Listeners

The Changelog: Software Development, Open Source by Changelog Media

The Changelog: Software Development, Open Source

286 Listeners

The Side Hustle Show by Nick Loper of Side Hustle Nation | YAP Media

The Side Hustle Show

1,582 Listeners

Software Engineering Daily by Software Engineering Daily

Software Engineering Daily

622 Listeners

JavaScript Jabber by Charles M Wood

JavaScript Jabber

234 Listeners

This Past Weekend w/ Theo Von by Theo Von

This Past Weekend w/ Theo Von

28,024 Listeners

JavaScript Jabber by Charles M Wood

JavaScript Jabber

62 Listeners

Syntax - Tasty Web Development Treats by Wes Bos & Scott Tolinski - Full Stack JavaScript Web Developers

Syntax - Tasty Web Development Treats

982 Listeners

The freeCodeCamp Podcast by freeCodeCamp.org

The freeCodeCamp Podcast

484 Listeners

PodRocket by LogRocket

PodRocket

59 Listeners

Whiskey Web and Whatnot by Skill Issue Studios

Whiskey Web and Whatnot

55 Listeners

Develop Yourself by Brian Jenney

Develop Yourself

7 Listeners

The Startup Ideas Podcast by Greg Isenberg

The Startup Ideas Podcast

211 Listeners

WEAPONIZED with Jeremy Corbell & George Knapp by Jeremy Corbell and George Knapp

WEAPONIZED with Jeremy Corbell & George Knapp

1,417 Listeners

Front-End Fire by TJ VanToll, Paige Niedringhaus, Jack Herrington

Front-End Fire

11 Listeners