Category: Uncategorized

I’m trying to transition an express node service to using the serverless framework and Google Cloud Functions.

No matter what I tried I kept running into an issue where i was getting this error:  Unexpected token : in JSON at position 19

category:
handler: category
events:
- http:
path: category/{id}
method: get
cors: true


After some Google searches I found this issue: https://github.com/serverless/serverless-google-cloudfunctions/issues/78

The fix was doing this instead:  - http: category/{id}

Let’s hope I don’t need to change my REST verb or set cors.

I have been working on building a PWA front end for WooCommerce.  I saw the Polymer Shop repository and thought it couldn’t be that hard to wire up to a real backend and get everything working.  I was right and I was wrong.

I started by creating a WordPress/WooCommerce install on Pressable.  This was really simple and took maybe 5 minutes.  I then populated it with the categories that I needed and a couple items to show on the site.

Next was to create node api server that could handle authentication because the wc-api requires auth to make calls.  This api server is also a great cacheing point since it serves one thing to many users.  It only needs to retrieve the data from the WooCommerce store daily or hourly in order to be current.  Again this was pretty simple and required only an hour of effort to get an express server running and making requests to the WooCommerce store.  The documentation on the WooCommerce API is pretty good.  Once I had the service working I pushed it to Google App Engine.  I have yet to add caching but plan to do so when I have time.

I finally had everything ready for me to dive in and get the Polymer Shop running off my service instead of hard coded arrays and json files.  First I needed to get the categories pulling from the api.  Easy enough but since they were hardcoded I needed the app to wait for the API to return before showing the page as a 404 since the category requested did not exist.  In the constructor I call the function that fetches the data from the API.  I also added some checks to wait for category data before declaring the 404.  Not to difficult.  Next was getting the items displaying properly.  Not too difficult, all I needed to was replace the json file with a fetch to the api server and modify the data format a bit.

Where I ran into problems.  I was at first attempting to use the PRPL node server but couldn’t quite get it working.  I struggled with this for a couple hours and gave up. I know now why it wasn’t working and will eventually get back to it.  The way I had it configured was serving the src folder not the builds. Once I removed that and decided to just serve the es6-unbundled version to start with I was moving again.

The next issue that I ran into was trying to get the service worker implementation to add the api and store urls so that it would cache everything it needs.  Because the Polymer CLI was building the service worker I had to add those urls to that build and I failed in figuring out how to do that.  I had used Workbox before and decided to just do my own implementation.  I ripped out the CLI service worker implementation and struggled with the instructions here.  What I didn’t realize was that you could not provide your own base service-worker.js with workbox-cli generate:sw what I needed was workbox inject:manifest which creates a manifest of the files and injects it into the source service worker you give.

Once I had all that in place everything was on easy street.  I pushed the frontend to another Google App Engine instance and I was done.

There is still lots to do:

• There is a bug where if you click around quickly it gets confused which category to use which then breaks everything
• Sometimes when you click on an item it takes a while to load and sometimes never loads
• When you first load the app it is really slow.

So in conclusion.  It is not World’s Fastest Store but could be with a few optimizations.  I have work to do but it is a beginning and also just a proof of concept.

I wrote here that I was going to live stream when working on the little project I have been working on.  I completely failed on that.

Here is why I failed:

• You need blocks of time.  I usually have an hour here or an hour there but never a scheduled block of time.  Random streaming just didn’t seem worth it.
• You need a stable connection.  When I’m home or at my workspace I have a stable connection.  When I am traveling I do not have a stable connection
• Travel.  I have been traveling a lot lately for Automattic Grand Meetup, team meetups, conferences, vacation, etc.  So hard to stream on travel for a variety of reasons.
• Noise.  My workspace is in an artist studio that can get noisy at times.  When working at home the baby tends to be a bit noisy.  It doesn’t bother me since I have headphones on but is not optimal for streaming.

So in the end I think streaming is not for my at the current time.  I really wanted to do it but like anything else at some point you need to admit that it isn;t working at try something else.

I did however get the project well along the way and will be presenting it at WordCamp Philadelphia this weekend.

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!