Description

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

• 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 huge help to me on a daily basis. Being able to put  a breakpoint in my code and view what all my variables read at that time makes testing and writing code so much easier

• With most software companies move to a monthly or yearly subscription model has the standalone application now become a unicorn in our industry?
• paying only 5-20 dollars a month for a premium application seems like a easier sell to people then asking them for 100+ upfront. But these 5-20 dollars a month add up and could very well be a much bigger hit on your wallet in the future
• Knowing you never own the actual product is also a weird feeling
• For the company having consistent recurring income is a huge bonus and allows them to plan much further ahead with features and support. Also very few yearly version upgrades happen, instead choosing to maintain and add features to the same version. This makes for less need to upgrade or migrate to different versions
• In my experience a company that gets a monthly subscription is less likely to abandon their product
  • I.e android app Weather Timeline was a paid application but with it being only a one time fee it wasn’t able to maintain it’s costs and had to take the application down from the store and later on sell it to a different publisher
• What do you prefer, a one time bulk fee (approx $100) or a $5-$20 subscription?

You can find us on...

Facebook | Twitter | Instagram  

RSS | Spotify | Reddit

Medium | YouTube | GitHub

Patreon