Category: Uncategorized

I am working on a talk and need to write a good bit of code to make that talk fly.  I don’t see why I shouldn’t live stream that work.  I don’t yet have a cadence for how often I will stream and don’t know how long it will last.  If I find that streaming is really slowing me down and I am not effective, I will stop.  If I find that I can;t stream on a regular basis, I will stop.  So, now that I have convinced you not to get invested in my stream, here it is: https://www.twitch.tv/belcherj

Here is my talk outline:

Building a Progressive Web App WooCommerce theme using PRPL principles, Polymer, and Node

Using WooCommerce, Progressive Web App, and PRPL principles I will show how to create an eCommerce store that it blazing fast even on slow connections and on less capable devices.  This talk and accompanying GitHub repository will delve into using the WooCommerce and WordPress APIs to power a front end JavaScript application and act as a reference implementation for creation of a PWA WooCommerce theme.

What will I be streaming?

I am planning to wire together https://github.com/Polymer/shop, https://github.com/Polymer/prpl-server-node, and https://github.com/woocommerce/woocommerce.  I will be pushing all of this up to the Google Cloud Platform.

Hope to see you soon!

Beer:

Garage Beer Company – Brew pub

BierCab – Bar and beer store.  Amazing selection in both.

BrewDog

Mikkeller

Lambicus – Bottle shop with tons of Lambic.  Get a bottle of Cantillion

Vivinos – Awesome boutique wine shop with good natural wine selection.  Get a bottle of BS

Kaelderkold

Tourist Stuff:

La Sagrada Familia – Most beautiful thing I have ever seen

Picasso Museum – Must go.  You can do this fairly quickly.  Explore the neighborhood around it.  El Born has many small artist shops.

Restaurants:

Somorrosto – Go here before or after going to the beach. Amazing!

Ciudad Condal

Tickets – This place looks awesome, we didn’t know about it till after we were there.

Cool Areas:

El Born – Not touristy, really cool with lots of little shops

Transport to City Center:

Aerobus – Buy tickets ahead of time.  Watch the youtube video on how to et to the bus.

Public Transport:

Buy T10 cards in the subway for use with Subway or Buses

Warnings:

Watch your wallets

 

If you know me you probably know that I sincerely believe that for a project to be successful you need to have both a style guide and automatic enforcement of that guide (linting).

I am always surprised when I speak with other developers, how few work on teams or at companies that have and enforce style guides.  This post will discuss the why so that we are all on the same page and ready to get started on creating and implementing a style guide on your team, company, and project.

So why do I need a style guide?

1. Avoiding bike shedding.  As developers we generally have a lot of strong opinions.  When syntax formatting is not agreed upon we will inevitably devolve into cave people arguing over trailing commas or spaces versus tabs.  A style guide allows your team to argue once, make a decision, and move on to more important things.  Once a team agrees on a certain set of styles it is then taboo to discuss syntax outside of formally revisiting a style guide.
2. Onboarding.  When new team members join, point them to your style guide as a first step before they jump into the code. Once a person understands the style and formatting it will be much easier for them to focus on the code rather than style.
3. Readability.  When a code base has one style it is much easier to read.  When you have to context switch between coding styles it is a distraction and decreases efficiency.  When you read a book and every third paragraph has a different style or formatting you have a bad reading experience, code is no different.
4. Team cohesiveness.  As a team when you write code in the same way you come to understand each other better.  You give your team something that you can all agree upon.  You may think of this as ridiculous but when you work on teams with diverse participants it creates a common ground where everyone is comfortable.  It gives you a starting point on which you can start bonds and friendships.  Nothing creates more animosity than seeing code formatting that doesn’t follow your view of what is correct.
5. Code Quality.  Cohesive style makes you think about the code you are writing.  It makes you take a another look at the code before committing. With a consistent style it is easier to see errors when code looks slightly off.
6. Code Reviews.  When you don’t have a style guide you spend time looking for style errors because they are the easiest to find.  Once you no longer have to look for formatting issues you can spend your valuable time actually reviewing the code and what it does.
7. Prohibits Laziness.  I have worked with people who thought doing certain things because they had to get a feature out was an okay thing to do.  The response was always, “I’ll do that in another commit”.  One such instance was adding inline styles.  When I finished that contract 8 months later those CSS styles were still there.

So why do I need to enforce a style guide automatically via a build system or git hooks (linting)?

1. If you don’t enforce a style guide no one will follow it. Once you create the style guide you will put it in your repo’s wiki and then no one will ever look at it again.  I have seen and heard this over and over.
2. Code reviews will start being about styling and not substance.  If you add it to the linting system no one has to worry about style.  Lack of linting also creates real jerks out of normally nice people.  I hate being the bad guy who points out style issues in every commit.  It makes me look petty and mean but someone has to do it. TBH If you don’t follow the style guide that we as a team agreed upon I’m going to call you on it. Automatic enforcement means that a computer is calling you on it not me.  That makes me happy again.
3. Commits will be squared away before they go into revision control.  Code will be at a minimum compliant before being pushed to github making it not possible for code with style  issues to be merged in.
4. Style guide enforcement tools also lint for errors.  This in and of itself is reason enough to implement.

What is holding you back?

1. Your team can’t agree on one style.  If your team can’t agree on style you have issues deeper than a style guide will fix.  If you come to an impasse setting down a team style guide it is time to make staffing changes.
2. You don’t have time to create and enforce a style guide.  It should not take more than a couple hours to a day to decide on a style guide.  It should take no more than one developer  no more than one week to implement.  The tools are quite good these days. You will get this time back within a couple months in code reviews alone.
3. My team lead, manager, product, business, etc doesn’t see the value.  Have them read this post.  If they don’t agree you should probably do yourself a favor and ask to join a new team or start looking for a new job.  Many times companies will find excuses not to implement a style guide.  You are not a unicorn, you are not special the same issues you face we all face.  Seriously, if they don’t see value here they won’t see value in anything but the quickest way to get features out.  Then they will be upset the code is buggy, difficult to maintain and, slow to change.
4. I am the only developer on the project why do I need this?  Will you work on and maintain this project forever?  What if the project gets bigger and requires other developers?  What happens if you leave the project or company?
5. This project will only live for a short period of time.  That’s awesome! The best time for a style guide is when starting.  If you do several projects like this add the style guides to your seed.  Adding linting should take an hour or two on a brand new project.  Just do it.  You never know when that project will take on another life.  You know that prototype you built that product let you throw away?  That has never happened.
6. I have a huge codebase how do I add linting after the fact.  I have added linters to code bases with hundreds of thousands of lines of code.  All new code gets linted.  If you make changes to a file fix the lint issues first then make code changes.  Over time this will help you get the whole code base compliant.  Linters these days are also really good at automagically fixing your code.  Make some of the styles warnings which will show up in yellow but not block commits.

My next post will outline how to create a style guide.

Till then, JB

What: A recorded video session where we discuss Web Technologies. I would like to focus on the browser, JavaScript, HTML, and CSS. Topics will be taken from recent happenings in the community and from what we are working on.

Where: The conversations happen in a Hangout On Air and are viewable live or recorded on youtube. See previous episodes here.

When: Every Friday from 16:00 to 17:00 GMT (11:00 EST, 09:00 PST)

Who: Anyone who wants to talk about Web Technologies. The limit of Google Hangout is 25 for on Air but I think that is too many. I’m not sure what the right number is but I suspect it is less than 10. You can ask to join by filling out this Google Form

How: Everyone gets on the Hangout a couple minutes before 16:00 and we start the hangout on time. I will create a calendar event and place the hangout link there.

Here is the ongoing Google Doc with topics to be discussed.  Edit access will be given to those invited to join the Hangout.

The idea is for this to be a very low time cost production. With work and a baby my time is limited and an hour a week sounds like the right commitment. If it is known that this is a live hangout on air the expectation of production value is not high. When I have done podcasts in the past we haven’t followed through because of the need for editing and transcription. Additionally without a regular schedule it will never happen. Let’s give this a try and see where it takes us!

I am excited to get going on this as the thing I miss about being in an office is the lunch time discussions about technology that I only get now by going to meetups.

I am open to comments and ideas.

Join us Friday January 20th:  https://www.youtube.com/watch?v=xN-Huef951s

I drink a lot of coffee. I write a lot of JavaScript.  This is about my journey from drip to my perfect cup.

I probably started drinking coffee sometime in high school and have been addicted to caffeine ever since.  Until recently I have always made coffee using a drip coffee maker and enjoyed the occasional coffee shop brew from time to time.  This usually entailed pre-ground commodity coffee from the grocery store.  Then three years ago I started working at Stuzo and they had one of those fancy K-cup makers.  This coffee tasted even worse than drip but it was fresh and quick.  One of my coworkers (Josh) brought in an AeroPress and would brew me the occasional cup.  This was amazing coffee.  He was also nice enough to let me use it when I wanted and I bought a bag of pre-ground coffee from a local coffee shop.  I remember my jaw dropping at the price of the coffee.  Why did this coffee cost three times as much as the store bought?  My other recollection was that it took me a very long time to go through the coffee because as time went on I found myself returning to the K-cups because of time constraints.  Every time I did use the AeroPress I would get upset with myself that I did not take the time on every cup because the end product was so vastly superior.  Two years ago a friend (Ben) gave me an amazing Christmas gift.  He came over to my house with a Chemex and a box of filters.  I proceeded to pull out my pre-ground coffee from the freezer and make coffee.  The Chemex yields much more than one cup which was a amazing in comparison to the AeroPress.  The coffee tasted amazing! I was hooked.  I took the Chemex to work and made a batch every afternoon sharing with my coworkers who thought I was a full on urban hipster. I used the Chemex fairly regularly for a couple months but then found that my usage fell and was opting for the office coffee which was quite possibly the most disgusting caffeine conveyance method I have ever used. That is saying a lot since I have made coffee using a clean but used sock in China. This last year things changed as my wife and I were expecting our first child.  We both knew that soon time would be at a minimum and caffeine would be a necessity. We purchased a French Press, a Coffee Grinder (Both Bodum), and a scale for the home to replace our drip coffee maker.  This was to get the best possible combination to get the best quality product in the least amount of time.  We now purchase our coffee in five pound bags from a local roaster, Greenstreet Coffee Roasters, because of the quality and the great price.  I grind the coffee each morning and make 700 oz of coffee with 60 oz  of grounds and fill a our thermoses.  I head off to work and my wife’s is waiting for her when she is ready.  I still use the Chemex at the office if I need an afternoon coffee.

What does coffee have to do with web apps other than keeping me nice and sharp?  Well, I think there is a decent analogy that can be made.  Both are pretty easy to make but if you want a truly unique and tasty cup it requires some additional steps that can get quite complex.

2016 was the year of JavaScript Fatigue posts and I never really understood the complaint.  You can still make a mighty fine website using plain html, css, and a little JS to make things a little fancier but if you want an app with more complexity the tools and process for doing so will be more complex.  I think the whole idea of fatigue is just silly.  Maybe I come from a privileged position of being paid to learn these things on the job because I came of age during the age of increasing front end app complexity.  The complexity that exists today within JavaScript apps is to me quite simple when compared with developing and deploying backend systems.  The complexity required for a web app is commensurate with the apps we build today.

We should use the right tools for the job.  If you need a cup of coffee stat to get you through the rest of the day a cup of drip coffee using store bought grounds or a kcup will do the job.  If you want something more complex only freshly ground, correctly measured, using a proper press or Chemex will do.  We shouldn’t complain about our tools and complexity, we should work towards making our tools better and providing better documentation for those tools.  When I first got the french press and grinder I watched many YouTube videos on their use.  Likewise, when I joined Automattic in April and started using React I watched all the videos about React/Redux on egghead.io and read all the documentation before I attempted to write any code.  I then proceed in building out my first React app.  I then went back and watched the videos and read all the docs again to ensure that I had a full understanding.  While I do not proclaim myself to be an expert, I feel that I am proficient.

I am not saying that todays tooling in the JavaScript world is easy but I think it is compensate with the complexity of the output.  Just like the coffee world, there is not one solution to any problem and if you are uncomfortable with the tooling required to create a cup of coffee make yourself a kcup.  If you aren’t satisfied with the result revisit your tools.  Add complexity as necessary.

One last note: Just because there are new tools available doesn’t mean you have to use them.  The Chemex has been around since 1941 and it makes an amazing cup of coffee. WordPress has been around since 2003 and creates amazing websites.  Find tools that work for you, learn them deeply and make something awesome.

Thank you to all the very smart folks that make all the tools I use on a daily basis!