Large Scale AngularJS App

December 18, 2015
Reading Time: 2 minutes

My list of how not to completely screw yourself over on a large-scale AngularJS project – The biggest project I’ve done has gone from Angular 1.0.x to 1.4.x. These are what my findings were:

  1. Setup the style guidelines right from the get-go. Seriously, this simple starting point will in the end give you at least the advantages of keeping code clear. John Papa has a community driven one on github that’s excellent.
  2. Get comfortable with directives. Review the way that some of the more popular ones are setup and created. DRY is your friend in any application, and doubly so in a large one.
  3. Be sure that everyone that is going to be working on the design end of it (CSS, LESS, SASS, etc.) are capable of the work. The more complex the CSS of the site, the more potential to royally screw up the UI there will be.
  4. I suggest having everyone watch at least the JavaScript Good Parts video with Douglas Crockford. It’s available on Pluralsight and I think Frontend Masters.
  5. Setup your Linters from the get go. JSCS and ESLINT are my preference. I also highly suggest Uncss and Stylestats for the UI CSS work that’s being done.
  6. Consider a LESS or SASS Library to standardize some basic mixins to use throughout the UI.
  7. If possible, get at least Directive unit tests working properly. It’ll save you many debugging headaches.
  8. Be sure to well document an actual snippet for your directives for use in a top of file comment block. Nothing more annoying than needing to use a random directive that requires you to read all the code to know how to use it properly.
  9. Most browsers work properly most of the time, until you open things in IE.
  10. Get auto-deploy setup to dev servers. Makes having the latest builds available to QA a lot easier when somewhat centrally managed.
  11. If you use $broadcast just throw your computer out of the window.
  12. Don’t roll your own translation directive. Use angular-translate or another community option.
  13. Get used to arcane console.log errors.
  14. If you encounter your app having infinite digest cycle errors, you’ll realize very quickly that they’re not easy to diagnose. I highly suggest reading my post on finding them in a large app and what worked for me.

I may add more to this list in the future – but have fun and make cool stuff!

Revise Your Release Schedule!!

February 7, 2015
Reading Time: 2 minutes

Why in the world do people/companies/etc. release on Fridays? It makes no sense from a time or problem solving perspective.

Consider this: You spend an entire sprint or two preparing the next set of app updates, to only find out after pushing it into production that there is a critical bug that was uncovered. Now, if you’ve setup your production environment correctly, you more than likely are able to rollback to the previous release with the use of Capistrano or some other tool. If you haven’t, well, then your developers and QA get an enjoyable weekend of not having a weekend 🙂

I highly suggest any serious company looking to minimize their employees stress, to do releases on Tuesday mornings. You get nearly the entire week to fix any issue and push the changes back out to production before the weekend without sacrificing your employees time off. There won’t be any disrupting your employees personal lives anymore than they already are, so as a result your employees will be happier.

The mindset of releasing on Friday’s I think is because of this innate human condition to want some type of closure at the end of something, such as the work week. Where-in you can release it, and then goof off the rest of the day at work, unless there is an issue in production then you know you may have no weekend and still have to work on Friday. I think most people can agree that actually breaking many of our psychological habits, are what will make us better at what we do, and be better poised to move forward with what we’re working on.

Just because something is what’s always been done, or something is the norm, doesn’t make it better or even the best solution. And in this scenario, I think it’s a horrible solution.

Software Planning Practices

January 25, 2014
Reading Time: 1 minute

One of the most important aspects I’ve found in software engineering, is pre-planning. And I don’t just mean a simple discussion either.

I’ve been keeping track of the different items really necessary to successfully complete most of the more complex projects I work on, they are (but not limited to):

  • Lo-Def Screen Layouts (Using Fireworks, Pencil or Visio)
  • Hi-Def Screen Layouts (Using Fireworks, Illustrator, Photoshop, GIMP or Inkscape)
  • Project Workfow (Using Pencil or Visio)
  • Project Description and What’s to be accomplished
  • Technology breakdown:
    • Is it html/css/js? Or is it in Java?
    • What libraries?
    • Do any new technologies need to be learned?
  • Timeline restrictions
  • Build phases and milestones
    • Major milestones and minor milestones in the phases and at the phase transitions
  • Hosting architecture
    • Will it be a cloud server? Or is it a single VPS?
  • Database diagram and planning
    • Stored procedures
    • Foreign Key (FK) Relationships
    • Platform, Engine, etc.
  • QA Requirements and Planning
  • System deployment and update handling
  • Development Style (TDD, etc.)

Feel free to post anymore things that you do to improve the overall development process for your projects.