Best Practices for Developers: OverZealous Creations

If you’ve ever been faced with an obstacle when coding you’ll know just how difficult it can be to solve it, sometimes you’ll spend hours trying to come up with that perfect solution, however with today’s awesome communities you’re always a few clicks away from a fix.

Phil DeJarnett, founder of OverZealous, is apart of communities like NPM that helps others by creating solutions for those really tough head scratchers. Today I’m happy to announce we’re joined by Phil to discuss the communities he helps, recommended frameworks, and best practices for developers.

Can you tell us a little bit about OverZealous and the idea behind it?

“OverZealous” has been my handle (online/gaming, etc) since the mid-90s, probably 1996 or so. Back then it was just a nickname for video games. I was looking for something fairly unique that reflected my personality. I tend to be overly ambitious in setting my goals—hence, overzealous.

I purchased the domain in 1998, and it became OverZealous Creations (OZC)—in other words, a place to show off my work. I was just getting into web development at the time, though assisting the on-site web developer for my university.

At the time I was building stuff in Macromedia Flash 3.0. This is pre-ActionScript. All “programming” was done by shifting between scenes, jumping between frames, and calling out to JavaScript for more advanced stuff. I’ve always been interested in creative-technical work, so I liked pushing the boundaries. The craziest thing I built before mostly leaving the Flash world was a hierarchical tree, with drag-and-drop nodes. It’s not fully functional on modern flash, but, surprisingly, you can still see on FlashKit!

Since then, I’ve shifted around between development languages (ColdFusion, Java, ASP, PHP, and Groovy at different times) and companies, building a wide variety of web-based applications and interfaces. Right now I’m raising my daughter, so I’m not actively employed.

You’ve been an active member of the community building modules on sites like NPM, which is a NodeJS package manager to integrate third-party node modules by other developers. Can you tell us why you decided to start “giving back”?

I’ve been contributing in one way or another for a long time. Pretty much all the critical tools I use daily are open source projects. I currently use applications like MacPorts, NPM, Mercurial, Git, IntelliJ, Atom, LibreOffice, etc, every day. I also rely on a heap of open source libraries to build applications and I believe that it’s important to use tools that are open when you can. I rely on a lot of closed-source tools, as well, simply because they are industry standards (Adobe products) or best-in-class for my needs (such as Mac OS X).

Open source tools have several benefits, such as:

• They are (often) cross-platform, making transition between systems easier.
• They can usually be used on multiple devices without extra licensing.
• It’s easier to dig in and find or fix bugs with them.
• F/OSS libraries are much easier to integrate into private and commercial offerings.

I started giving back simply because I like sharing knowledge. I’ve been an active member on StackOverflow for the same reason. I found out about gulp in March, or so, and while initially skeptical, I quickly decided I really liked the concepts behind it. I found a project to work on (translating the ngBoilerplate’s Gruntfile to gulp), and that led me to writing a few modules, and writing an article. This was pretty much how I got into NPM. NPM is pretty cool because it has an extremely short learning curve. (This is in contrast to Maven repositories, which I have never really bothered to deploy to.)

Frameworks are a good place for devs to start building their skills as they help develop better and faster applications in a structured environment, not to mention they save a lot of time with pre-built functions. For anyone new to frameworks which ones would you recommend?

I hate to recommend any specific framework, because you really need to evaluate the tools against your project, and try to pick the best fit. I also was fortunate enough to learn alongside many of the frameworks as they grew, so (on the front-end) I worked my way through Prototype.js, Mootools, jQuery, and have recently settled in with Angular.

I personally really like Angular for front-end work, since it reflects the back-end tools I am most used to (like a Spring/Grails setup). I tend to be a bit anti-jQuery (which will probably draw a ton of ire, but whatever). jQuery just has a nature that leads to hard-to-maintain code, especially if you build something big. Angular has two key concepts that make it stand out:

• Modularity: It’s extremely simple to build an application up out of logically-related components, as well as reusable components.
• Testability: Because it relies on inversion of control (IoC) & dependency injection (DI), Angular modules are very easy to test. Testing, when done correctly, leads to better code. Better code means easier maintainability.

Of course, there are other frameworks out there that may fit your project better (Backbone or EmberJS are popular). I just feel comfortable with Angular, and if someone comes from a IoC/DI/TDD background, maybe they would, too.

Technology has become ubiquitous to the point anyone with a smartphone or tablet can view your site, but this doesn’t come without it’s challenges. Different screen sizes and resolutions give users a disjointed experience, however with responsive web design everyone gets the same journey from start to finish. How important would you say a responsive web is for the future?

I think that we’ve already reached a tipping point where a functional site on mobile is more important than an impressive desktop site. I find myself, as well as many other people I know, experiencing new content through my mobile phone first, almost every time. And I get tired of visiting a website only to have to mark it to view it the next time I am sitting on the computer.

It’s still very difficult to be effective—especially if you aren’t starting from a CSS framework. The difficulty isn’t in the technical side, necessarily, but the design and planning side, where you now have to plan for two (or more) completely different ways of accessing content or manipulating data, without burdening the user in either one. When done correctly, though, it’s amazing.

As the market on the web gets saturated with more and more companies it can be difficult to stand out from the crowd, so it’s important to give users the best experience possible. What aspects do you take into consideration when building a website to improve user experience?

First, and most importantly, is providing a tailored experience based on the user’s device, what their goals are, and how you can best help them achieve that. A perfect website or application is one that gets out of the way and gets you to your goal quickest.

Second, probably load time. By this, I mean total load time, not just server-to-browser. I’m pretty tired of developers who think that throwing multiple 70+Kb libraries on a website for just a few features is fine, since “it isn’t that big”. The fact is, bytes matter, and the first visit may be your only chance to get a user to stick around. Don’t assume caching will help on repeat visits either, since caches get emptied.

• Too much JS or CSS can seriously slow down a mobile device, so only use the libraries you are getting a benefit from.
• Have a build process in place that can automate everything, including minification, GZipping, combining assets, whatever you can do.
• Judiciously use CDNs (in fact, bundling all your JS into a single file might actually hurt load time, so test and test again).
• Don’t use generic assets (like FontAwesome) when you can build custom-tailored assets using only the pieces you need (see gulp-iconfont)
• Use long-term caching with tools like gulp-rev, so your users can reload the page faster the next time if their cache still has the file.

Third, aesthetics. Every site should look good, but flash is only necessary if you’ve covered steps one-and-two. When you can, spicing up a site with good, subtle animations, transitions, and effects can improve the experience.

You’ve built a few modules for Gulp, which is a front-end build to optimise developers front-end performance. What would you say are your best tools when it comes to speeding up your dev time?

You must work with a versioning system. Personally, I prefer Mercurial for my projects, but Git is functionally equivalent and far more popular. If you want to be able to contribute back, you’ll need to learn the basics of Git, no matter what. Using any VCS will save you time, save your neck, and give you confidence when making changes. Even if you are the sole developer, Distributed VCSs (DCVSs) are still useful. I develop on multiple machines, depending on where I am, so I love being able to commit-push-pull-update and have everything ready on the other box.

A good build system, whether gulp, Grunt, or whatever you prefer, is critical. Being able to clone your repo (see above), run one or a few commands, and have the entire codebase linted, tested, compiled, minified, etc, means you can iterate faster. Add continuous integration (such as Travis-CI), and possibly even roll deployment into your build script, and you can make changes and get them out live much quicker, freeing up more time for building features or refactoring your existing code.

Use a CSS preprocessor, such as Less, SCSS, or Stylus. This not only helps you write simpler, more accessible CSS, but reduces redundancy, and allows you to easily set up variables for site-wide settings, like colors and sizes.
Not every one will agree, but I think it’s important to have a good IDE. It’s fine to use simple text editors, but IntelliJ (or one of the lighter-weight JetBrains IDEs) provides a ton of real-time feedback when editing code. Being able to quickly get suggestions for variables and less-used features is great for me.

That being said, make sure you can fully build and deploy your application without relying on your IDE, or any other GUI apps. The last thing you want is to have to manually replicate your build environment across multiple developers or computers. NPM and Bower happen to be good tools for this, since both allow you to maintain dependencies on a per-project basis, and install updates easily.

Livereload (or browser-sync) has quickly become an essential tool for web development. When integrated properly with your build process, you can simply make a change, hit Save, and see your changes in one or multiple browsers. With browser-sync, it will even maintain scrolling and form data. I haven’t use it yet, but it sounds like it will replace LR for testing on multiple devices & browsers.

I’m still a big fan of Firebug, but for web-based front-end, knowing multiple browser’s developer tools is critical. You need to know how to run code against your active application, dig into the live HTML, set breakpoints, modify CSS, etc. It’s surprising to me how many younger developers are unable to debug problems in their own code. It’s so much easier to see inside active web code than it is, for example, compiled code.

As the web moves forward we’re seeing more structured methods when it comes to building sites or applications to ensure quality products and services. What best practices do you follow that everyone should know?

Like I said in the tools section above, I think it’s critical to have use DVCS, even for tiny projects.

Security should always be a foremost concern, especially if you accept any sort of user or other outside input. I always try to assume that everyone is trying to attack your server, whether they are logged in or not. Every action that can modify data—or access non-public data—needs to be secured somehow.

One thing I’m migrating toward is a clear separation between front-end and back-end. It’s still somewhat common to have a unified server that renders finished pages. However, since we’re moving to a world where data is accessed from lots of different devices and front-ends, it makes sense to have your data served up via a clearly defined API, so you can build a front-end however is best. This doesn’t mean you have to have all-JS front-ends, necessarily. You can still have a server-side page compiler, but it should communicate via the same API that a JS or native application might use. This forces you to handle security and information better, as well as think about what parts are data vs what parts are simply GUI stuff. As a side note, it’s much easier to serve more of your content off a CDN if you separate your front and back ends.

Testing should be a part of everyone’s toolkits. Even in my tiny gulp plugins I’m trying to write good tests. I’m still pushing myself to do proper test-driven development (TDD), where the tests come before the code. No matter how you do it, though, good tests that focus on testing functionality and capturing edge cases (and bugs) help reduce errors now and in the future.

Have you been working on any projects that you’re excited about or any upcoming ones?

Sadly, there’s nothing much fun on my plate right now.

I’ve always been a sort of artistic/crafty person. I’ve always liked building and creating things, and it was a sort of natural transition to building things on the computer. We had a Commodore 64 when I was growing up, but I didn’t really start trying to program until I decided to write a character-based version of Space Invaders on my TI-85 calculator. I ended up sharing this with a lot of other kids in high school.

I chose Computer Science over Graphic Design in college, simply because I didn’t want to spoil art by making a career out of it. In college I worked tech support, which put me in the same department as the on-campus web developer. I started helping him (Allaire ColdFusion on top of an Access Database, and tables galore!), which is where I really started to combine my graphic design and technical skills.

From there it’s been a series of jobs that keeps me connected to web technology. The furthest I got was working with a friend trying to build a custom A/V company (home theaters, home automation, that sort of thing). But even then I was building the websites, and programming devices to interact with each other.