I decided recently to branch out a bit, and see if I could start using a new medium to talk about the web development craft. I am starting a new stream at twitch.tv/bettercalldoll on Tuesdays (and another random night of the week) to answer questions that new or experienced web developers might have. The first stream went well, and so far the feedback has been great! Follow the Twitch channel or watch for posts from @bettercalldoll to find out more information.
Jest and URL Mocking
I currently ran into a problem while testing some utility functions on a project. We needed to look at the window location to check query string parameters in order to see if our custom parsing was working correctly. Using our favorite JavaScript testing solution, Jest, the standard way of mocking the URL (until it stopped working) was like so:
Object.defineProperty(window.location, 'href', {
writable: true,
value: 'https://www.somthing.com/test.html?query=true'
});At some point, this stopped working based on what I believe was an update to the version of jsdom that Jest uses under the hood. For myself, and other developers needing to mock window.location values, this was frustrating. You can see others have had this same problem, as found on the Jest issues board on GitHub.
After searching that thread (and other postings), I finally found this little gem hidden amongst the posts. In your Jest configuration, make sure to set the following:
"testURL": "https://www.somthing.com/test.html"Then in your beforeEach() section for your test, change the path as needed by using history.pushState().
window.history.pushState({}, 'Test Title', '/test.html?query=true');Voila! Now you change out your path for any test, without having to override any jsdom configurations as others suggest in the thread mentioned above. Not sure on which thread I found this solution on, but kuddos to the dev that posted it!
SonarQube With Docker For JavaScript Or TypeScript Projects
SonarQube always seemed a little daunting to me, and I never really gave that much thought to it. How wrong was I! While Static Code Analysis might not find invalid business logic, it does help find security issues and it can sniff out code smells that your team has grown accustomed to. It might seem hairy to set it up for local developers, but it's actually quite easy with the help of Docker and npm!
Things you will need installed on your computer in order set this up:
Adding to Your Current Project
Adding SonarQube to your current project is a simple and effective way to help setup quality gates around your current, or new JavaScript or TypeScript codebase. The example below will show you what files you can add to the current Angular GitHub repository without affecting the existing structure of the project. You can use this boilerplate to start off any project.
SonarQube Docker Image
The first thing we will need to do is pull down the latest Docker image of SonarQube to run locally. If you currently are using Docker and Docker Compose for local development, you can just add this image to your existing docker-compose.yml file.
- Pull down the latest SonarQube docker image:
docker pull sonarqube - If you want to leverage Docker Compose and make the container setup easy to share, all you need to do is the following:
- Create a docker-compose.yml file in the root of your project:
version: '3' services: sonarqube: container_name: sonarqube image: sonarqube:latest ports: - "9000:9000" - "9092:9092" - To start the container:
docker-compose up -d - To stop the container:
docker-compose stop - To remove the container:
docker-compose down
- Create a docker-compose.yml file in the root of your project:
- If you would rather create the new container by hand and not use Docker Compose:
- Create the instance of the container:
docker create --name sonarqube -p 9000:9000 -p 9092:9092 sonarqube - Start the container:
docker start sonarqube - Stop the container:
docker stop sonarqube - To completely remove the container from your system:
docker rm sonarqube
- Create the instance of the container:
After your container is up and running, within a few moments you should be able to visit http://localhost:9000/ in your browser and see that SonarQube is up and running.
SonarQube Scanner
Now that we have SonarQube setup, it's time to setup the SonarQube Scanner to run against the codebase. The easiest way to install the scanner is by using the npm module sonarqube-scanner. Alternatively, you can scan your code without the usage of node or npm, but it would require setting up SonarQube Scanner by hand. However, I wouldn't recommend it considering how easy it is to setup with npm.
- Install sonarqube-scanner as a development dependency for your current project:
- For npm:
npm install sonarqube-scanner --save-dev - For yarn:
yarn add --dev sonarqube-scanner
- For npm:
- Create a sonar-project.js file in the root of your project with the following code:
const sonarqubeScanner = require('sonarqube-scanner'); sonarqubeScanner({ serverUrl: 'http://localhost:9000', options : { 'sonar.sources': '.', 'sonar.inclusions' : 'packages/core/src/**' // Entry point of your code } }, () => {});- For a list of all the different options you can pass into the scanner, visit SonarQube's documentation
- By default, when scanning a project that has a npm package.json file, the reporting tool will use the package name and version that it finds in the JSON file.
- You can also pass along your test coverage results into the scanner for SonarQube to parse into it's results. More on that in a future post.
- In your package.json file, you can update the script section to add the command to execute:
"scripts": { ... "sonar": "node sonar-project.js" }, - You can now run the scanner:
npm run sonar- The scan will take a few minutes the first time to complete, but it will be faster for each subsequent run
- At the end of the run, you will be prompted with the URL to the project's results
- Be sure to add the
.scannerworkdirectory to your.gitignorefile so you don't accidentally commit it - Start to reap the rewards of static code analysis for your project!
What does it tell you?
If you are not familiar with SonarQube's analysis, let's pull down a well-known repo and see what it finds. I have a fork of Angular's source on GitHub that you can use for testing:
https://github.com/ryandoll/angular-sonarqube
You can see for yourself how easy it is to get started:
git clone git@github.com:ryandoll/angular-sonarqube.gitcd angular-sonarqubedocker-compose up -dyarn installnpm run sonar- Visit http://localhost:9000/dashboard/index/angular-srcs in your browser to see the results
The SonarQube results are very interesting for the Angular project. I love the fact that they only have one hour of debt for 12K lines of code! Play around with the results and get familiar with what SonarQube finds. I will start working on a future post about common configurations for SonarQube. For now, the basic setup is a good litmus test for any team to start implementing right away.
2015 Introduction to Ember.js
Found my old presentation that I gave back at KCDC in 2015. Had a great time presenting it!
Leader vs. Manager
Some thoughts I’ve had lately while preparing for my next round of talks focusing on leadership...
I hate being referred to as a manager, I prefer the term leader. Too often in the workplace the term manager is associated with the person to whom you report. A leader, however, may have those same responsibilities but also focuses on guiding others from within the team. A strong leader makes it easier for others to follow his or her vision or goal.
That said, management still has it’s place. Certainly, I have to manage my developers and give them direction and feedback for specific tasks. Management is a sub-task of the leadership role. However, as the leader becomes responsible for multiple teams, the management role increases. I will focus more on the leadership role and responsibilities in my talks, rather than the management aspect.
Having the title of a lead does not mean that others will naturally follow you. In fact, it could be quite the opposite! Some developers might resent the fact that an individual has been promoted to a leadership role. Sometimes the promotion is just part of the natural progression of the company, and not directly tied to the promoted person’s career path or goals. This can be problematic if the developer just wants to be promoted for the pay raise and doesn’t have strong leadership skills. He or she may end up frustrated and not perform well in the new position.
This poses the question: Are leaders born or made? I say both! While I was not a natural leader as a kid, as I got older and entered the workplace, my interpersonal and leadership skills developed. Over time, others saw potential in me. I got promoted into management early in my career, and in hindsight, I don’t think I was quite ready yet. I had a lot to learn about coaching other developers, especially those whose skills were more advanced than my own. Over time, I learned that a leader doesn’t necessarily have to be the best developer on the team. A good leader's breadth of knowledge and coaching expertise can not only help the team succeed, but also helps individuals progress in their career.
Focus on being a good leader first... opportunities and developers will follow.
Speaking
I have had the privilege of speaking at three different events this year…and I am really starting to enjoy it! Big thanks to Iowa Code Camp for letting me come and speak on Performance Budgets yesterday at their winter conference. I had a great time presenting at their spring conference earlier this year on interviewing developers, and my enjoyment of this conference continues to grow. I get to catch up on a lot of audio books and podcasts when I drive up to Iowa!
Also, this summer I was lucky enough to get my one of my KCDC presentations recorded by InfoQ! If you want to see me in action talking about Ember.js, you can watch it here: http://www.infoq.com/presentations/emberjs-intro. KCDC is a great developer conference in Kanas City, and I am looking forward to submitting a few more talks for next year!
Iowa Code Camp
I had a great time attending Iowa Code Camp a few weeks back. I would like to thank all of those who attended my session for their questions throughout! There was such a great mix of thoughts and questions that came from the audience, that I plan on altering my talk to focus on some topics they brought up. That's the great thing about speaking...your talk will always evolve based on everyones feedback.
If you do attend a conference, please make sure to give feedback if you are given the opportunity. Please let the speaker know what you would like to hear more of, or less of. That kind of feedback can help shape their next talk.
My next presentations will be at KCDC here in a few weeks. I am going to spice it up this time with a new talk on Ember.js.
Great Pointers for Speakers
I watched the following video by Ben Orenstein last year, and it definately gave great points on being a better presentor. Prepping for my talks this year reminded me of it, and I HIGHLEY encourage you all to watch it!
KCDC
I am excited to announce that I will be giving to talks at this year's Kansas City Developer's Conference! It is defiantly a perfect time to meet up with some great tech speakers and get your networking game on. I would encourage you to attend, and definitely check out one of my talks:
FizzBuzz Buzzkill: Rethinking the Developer Interview Process
Hiring great developers is vital for your company's success. By focusing on key areas of an interview, you can identify great talent as well as promote your company's culture and career opportunities. This presentation will be geared toward technologists involved in their company's interview process, and how they can influence it to attract the best talent.
An Introduction to Ember.js
Does managing state in your single page app seem harder than it should be? Do you suffer from transclusion confusion? Let's dive into Ember.js, and learn why many developers have fallen in love with a framework that focuses on convention rather than configuration.
Jaded
HTML template engines really challenge my beliefs about the current state of build processes for client-side development. They do simplify building static sites, and help you reduce repetitive HTML throughout your codebase. However, I have a hard time recommending using one all the time because it feels like it adds one more layer to an already growing front end stack. In my mind, HTML is pretty simple enough, so why would we need to complicate things by adding in one more thing? It seems like there is a new tool every week for Gulp or Grunt that developers can't wait to add to a project.
My overall decision on HTML template engines: larger projects with multiple developers can definately benefit by using them. Choosing the right one really depends on your project, as well as the learning curve it might add for the team. I recently had to seriously evaluate the use of Jade on a project, and determine if it would be the right fit for the task.
I coach a few developers at my job who use Jade daily, and always sing it's praise. However, I have always had on main problem with Jade...the syntax. While I could see their point of it enabling you to write less code, using Emmet within your editor of choice made writing HTML easy enough to not warrant a HTML template engine for syntax alone. By not knowing all the benefits of using it, and only focusing on the syntax, I never could warm up to Jade like they could. I figured I would never end up recommending it on any project.
A few weeks back, I started architecting a project at work for a pure client-side piece that would need to be very flexible and modular for future use within a CMS. Knowing that I would already be recommending Gulp as the task runner for the build, I was planning on using Assemble to build out our templates for the site. I had used it earlier in the year with great success. The only downside was that the Gulp plugin for it was currently in alpha, and given the status and rapid speed the project would be iterating at, I couldn't take the risk of an alpha plugin being a part of the build.
After digging around for some other ways of including Assemble into the project, I knew I would have to really start coming to grips that Jade would be the best candidate for the task. It came down to a few points that, given the project, would heavily influence my decision.
Breaking out reusable sections of client-side code is a must for this project. For instance, using a CSS preprocessor like SASS to build mixins for CSS styling is an easy way to keep styles clean and reusable. It is the Extract Method refactoring method that all developers should be using daily when writing code. HTML can also take advantage of this same principle when using Jade mixins and templates. Client-side developers can easily create reusable components for use throughout an entire site. Changing one small Jade template would implement a change across multiple static pages. Later on in phase two, this would not be an issue because the individual components built would be rendered via a server-side CMS. But for phase one, this would be key for the static only site.
Having a team working efficiently during tight deadlines is vital for my company. My team was already very comfortable with Jade, and by letting them continue to work with a toolset they preferred, I would not be hindering their development speed. I had already made a few architectural decisions that were not part of this team's normal workflow, so adding in another change was a risk I was willing to make if the technology itself was worth it. Jade seemed like a win-win: My team would be able to work quickly with a tool they were used to, and the architecture of the build would be solid. Regardless of my initial thoughts, Jade was a solid choice for the project, and I am glad I didn't try to reason my team away from it based on my original disdain on the syntax alone.
One thing to remember using these kind of tools in your workflow: Don't forget to document your templating process/folder structure. Teams that are used to working with a framework like Jade should start documenting mixins and creating an agreed upon style guide. In this project's case, we will be handing over the build process to another team to possibly implement down the road. By documenting what functionality exists within the templates, the learning curve can be reduced for the new team.
Take Jade for a spin in your project, and let me know your thoughts. There are other libraries out there like it to consider (Assemble being the other one I enjoy). Regardless of which you use, learn to take advantage of them for your static site builds.
Consistency
Consistency is something I have lacked this last month. I want to blame it on a busy work schedule and spending time out of town visiting family over the holidays. However, part of it has just been my own fault as well. Trying to write a post weekly turns out to be a little more difficult than I thought. But, I have been getting some great hands on exposure to things I have been wanting to dig deeper into over these last few weeks like Jade and Gulp. With new years coming this week, I figured I would revise my resolution to writing blog posts on technology: Write as often as possible, and accept that life may get in the way a bit.
Up next will be some thoughts on Jade, and how we are using it on a project at work. It is a valid tool, but I am still struggling with adding one more layer to a build process. More to come, hopefully later this week!
Leveling Up
A few weeks ago, I was going to focus on one specific technology per week, and then try to write up something about it. In practice, this does work great. However, given my schedule, it's harder to dig into working code when I get the free time. As you can tell by my posts, I am already behind one week...
It did come to me that I should not restrict my one-post-per-week rule to a technology or library that I need to develop in. Rather, since I mentor other developers at my job, I should also hit on subjects outside of the nuts and bolts of coding. It's other skills besides coding with a specific framework that has helped me to succeed in the last several years, and others might benefit from the things I have learned. One of them, is how I learned to level up my career.
Leveling up is a common term used in video games when your character gains enough experience to learn a new skill or skills. For example, by leveling up in a game you can use a more advanced weapon, or gain entry into specific sections of the game that you couldn't access before. If you are trying to increase your characters skills rapidly, you need to focus on leveling up. There are two main ways you can achieve this:
- You can gain a bunch of experience in a short amount of time by fighting a few tougher foes, with the risk of losing the battles due to the tougher challenge. The risk is worth the reward.
- You can gain a bunch of experience spending a lot of time defeating smaller foes. The lower risk is worth the lengthier time to gain the experience. You can almost do this type of leveling up passively in the game while doing something else.
If you want to be a better developer, you need to level up your career. I think the video game analogy options above fit perfectly in a developer's career as they are trying to progress. Now, granted, you can still gain skills as a developer over time just by doing your normal development tasks at your job. You will have tasks that are sometimes challenging, and other times not. Depending on the type of development or projects assigned to you, you could gain a massive amount of experience in a short amount of time. For those feeling that their day-to-day tasks are not leveling them up very fast, this post is for you.
Higher Risk Leveling Up
Everyone wants to learn the most they can, at the quickest rate possible. For a web developer, there is no way faster to learn a technology than being dropped into project and having to learn that technology on the fly with a tight deadline. Congratulations, you now have 100% focus on that technology whether you like it or not! This is a super high risk situation since there is little room for failure. You will learn, but given the project, you might learn the wrong way to implement the technology or not have enough time to refactor and deliver a product with too much technical debt.
However, some developers thrive in this type of situation. Their learning habits and personal lives' schedule may be able to adapt to this, and they will be able to make great strides in their expertise. They embrace these challenges, and find that "trial by fire" makes them a better developer. I tend to learn this way, due to my job at a fast paced marketing agency.
Lower Risk Leveling Up
As I mentioned earlier in the post, my schedule definitely can work against my goals of learning new things. However, I have learned over the last year that I can still learn a ton of information passively while I do everyday tasks such as commuting, or mowing the lawn. Podcasts are huge in my leveling up strategy, and they should be in yours as well. There are great podcasts out there that cover a variety of topics that will help your career, and all of them are free. I look forward to the boring car drives and time on the treadmill at the gym because I can knock out a few podcasts covering new technology while not even adjusting my schedule.
Reading books is an obvious choice, but does take a little more time out of your schedule and can cost some money. However, your career will flourish if you can read one nonfiction book per month focusing on a skill you want to learn more of. It really doesn't take that much time, especially if you follow my next advice...
Cancel your TV cable subscription. Seriously. I know this might sound like sacrilege to some of you, but there is no bigger time vacuum than the TV. The average american watches more than 5 hours of TV per day!. If you have a show you love, consider buying the season of it on iTunes or Amazon, and watch it...and only it. You can stay caught up, and still save a ton of money. By cutting out cable from my schedule, I have more time to spend with my family and find opportunities to better my career. It's probably the toughest thing in this post to do, but it is well worth it.
Take on a side project for a friend or relative. Try to find something that would allow you to experiment with a new technology, and allow you to adjust the schedule of completion. This way, you can take your time learning the information, and provide a quality product. Just be careful that you don't sign yourself up for too much work.
How do you level up?
I am always learning new things, and I know you are to. Leave a comment below and let others know some easy (and maybe hard ways) to boost their web developer experience.
Style Guides
Style guides can be beneficial to your development process. Most sites that I see worked on do not have a base style guide set up for them for all of the different elements on a webpage. You can find an example of what I am taking about here.
Granted, not all HTML elements will be used on the average site, but it can still be a great thing to test your styles against a single static page for a sanity check if you notice some weird styling happening on your site. Some developers might argue that this would be difficult with the type of site they are building due to multiple module types, and style rules changing out based on what modules are being used. I believe it might be a bit trickier to implement, but it can in fact be done...
I have seen an excellent solution on a project where the developer utilized Gulp to break out each of the different Handlebars templates being used, and with the help of Assemble, create a great site outline that showcased all of the different modules being used on the site. This would automatically be updated when the developer changed any Sass or HTML partial, and the output generated was easily passed off to the client for their review and reference. This is a great use case for leveraging your build process to output something else other than your normal asset flow.
While not the most amazing thing, small items like this added to projects really go a long way when turning over code to a client for them to implement.
Thoughts on Sass
Writing CSS can be tedious. Period. I have been doing web development for over 10 years now, and yet sometimes dealing with a CSS compatibility issue still can give me more heartburn than anything else. With the amount of trouble you can go through with browser compatibility alone, why make your life more difficult by writing all your CSS by hand?
You need a CSS preprocessor.
Most of you are familiar with what a CSS preprocessor does, so I won't go into the details of what they do. But, let's go into all of decisions/thoughts that drive me to recommending Sass as my daily driver.
So which preprocessor do you use? LESS, Sass or Stylus? I work with and coach many web developers at my job, and the flavor of choice that I have seen over the last few years is Sass. I don't think I have seen anyone develop in LESS at all, and I can count on one hand the amount of devs that fire up Stylus as their day-to-day. With that said, I tend to go with what I see the market trending with since I don't see any show stopping differences between them all. Since I am focused on creating front end architecture for projects where code could be passed off to other developers and even other companies quickly, I continue to choose Sass because of its popularity.
However, just because someone says they are using 'Sass' in their project doesn't give you the whole picture. I recently had a .Net developer say that the CMS we were using could handle all the .scss compiling because it was using Sass, and our workflow could be simplified. While his gesture was sincere in wanting to help out with the build process, in the end, that version would cause some issues. More on that later...
Choosing Sass seems like it should be the only commitment that you need to make when choosing a preprocessor. However, that is only the first step. There are several ways of running Sass, and all of them have their advantages and disadvantages. Not only can you choose what framework to run on top of Sass, but you can also choose how you want to run Sass, including which binary to execute against. Let's go into these options for a bit...
After you install the Ruby Gem for Sass, you can be up and running. So in theory, you can just start banging out nested classes and mixins with little setup. But, as all of us front end developers know, using a tool should never be that simplistic. We need more layers to add to our projects! Say hello to Compass.
Compass was the first way I got into running Sass a long time ago. It has some great mixins, and it's ability to create sprites was easy to add into your workflow. All the cool kids were using it, so it just naturally found its way into many projects. Dropping in a simple config.rb to setup your paths in your root directory, and running 'compass watch' in your terminal was dead simple. Plus, that configuration was easy to commit to your version control system so other devs could get up and running without the need of Grunt or Gulp. With all the power that comes with Compass, there lies one big problem...speed. Waiting on your .scss files to compile during your Grunt task was painfully slow. Slow enough to cause you to start drinking...Bourbon.
Bourbon definitely can take the edge off (in more ways than one). Bourbon runs noticeably faster than Compass, since it is just a lightweight library of mixins. While it is installed via a Ruby Gem, the logic itself is all contained within .scss files. Instead of another Ruby process like Compass to execute logic, all you need to do is include the Bourbon files and run Sass like normal. Some of Compass' mixins can easily be replaced with using Bourbon's (in some instances, the mixin names are even the same). If you need some more typography mixins, variables and functions you can add in another library like Bitters to help fill the gaps. So, unless you need all of the functionality of Compass, Bourbon seems to be the clear choice.
However, some people are not a fan of having to add Ruby to their already complex build stack. As I hinted to earlier, developers came up with writing a Sass compiler in C called LibSass and it is currently being used in one of our .Net environments. Not only does this remove the requirement for Ruby, but it also compiles MUCH faster. This can be thrown into a node.js build script using node-sass. Sounds like the perfect fit, right? Well, not exactly. While LibSass might have the edge in speed and portability, it lacks in functionality. Since it is a port, it has often been behind in features compared to the Ruby version, and those minor differences could end up causing headaches for teams depending on it. For instance, running the latest build of Bourbon with LibSass causes errors, due to C version discrepancies on functionality needed by Bourbon's mixins. However, it was recently announced that Ruby Sass is going to wait for feature parity with LibSass before moving forward and will then try to be maintained at the same speed. This is huge news, and will help out the Sass community. It will also get server side developers interested in adding it into their workflow as well since they can avoid the Ruby stack altogether.
So, where does that leave me with my current workflow? It's easy to install LibSass with Homebrew, and then wire that into my Gulp flow. However, the ability to have a nice library like Bourbon that stays fairly updated in my workflow outweighs the pure speed gain of using LibSass. So, it looks like Ruby Sass + Bourbon will be the preprocessor stack that I recommend for the time being until LibSass catches up. Then, I have a feeling a lot of people will start making the shift, including myself.
One week at a time.
Web development can be a pretty intimidating sometimes, especially with the sheer amount of technologies and libraries available to use. I get the to "talk the talk" in my everyday job, but that often doesn't lead much time for me to "walk the walk" when it comes to implementing some of the newest methods. Over the next several weeks, I am going to focus on one technology/library per week being used in the client-side development process and try to implement/experiment it in a way I haven't before. For some of those libraries, the new way will be the first time I have implemented it in anyway at all!
This first week's challenge will be Sass, and working on different versions of the runtime. Most likely it will be focusing on the Ruby version, and implementing BEM for a simple site.
Living History at Union Station
I just finished up helping out with one of the coolest projects that I have ever worked on at VML during my 9 years here. This video sums it all up for you, and I highly recommend if you live in Kansas City to download the app and head out to Union Station to try it out! Also, notice the handsome gentlemen posing with Truman at 0:48 in the video ;-)
BarCamp Omaha
I recently had the opportunity to give at talk on interviewing web developers at BarCamp Omaha (See the recording below). Some senior developers get the great opportunity to partake or even head up the interview process with potential candidates. This talk is geared at those developers, and focuses on the ins and outs of a technical interview. It also focuses on one key thing that the interviewer should always remember during the interview: Sell your company!