All posts by 3WatersAdmin

APIs Everywhere ( JAMstack )

Everywhere I turn there is a new API and the list is growing day-by-day. Amongst all the buzz there was another message being broadcasts… It was the “JAMstack”.

What is the JAMstack?

  • “J” for JavaScript
  • “A” for APIs
  • “M” for Markup
  • “stack” for the technology needed to accomplish this feat

image attribution (https://www.smcculloch.com/code/netlify-contentful-jamstack)

But what is the JAMstack really? I know the “MeAN stack”MongoDB, Express, Angular, and Node. I thought knowing the definition of the acronym would help me understand this new methodology, but it didn’t. All these terms are just that, terms. So, it was time to dig into this new phrase and see what all the buzz was about.

Basically, JAMstack was an idea created by Netlify. In my opinion JAMstack is a philosophy more than anything else. I say this because there are no rules, limitations or examples that you “must” follow. As far as I could discern it is the philosophy of serving static page sites that have API data displayed in them the best way you can. In this post we will breakdown some of the things I learned. By no means am I an expert on this. I took some time to investigate it and here I will present you with my findings.

Below we will cover some key parts of the JAMstack you should become familiar with if you plan to become a pro at it.

Breaking down the JAM-stack

  • Static Site Generators (SSG)
  • Hosting Services, or CDNs
  • Postman
  • Go Template Language
  • JavaScript (nuff said)
  • GraphQL
  • Headless Content Management Systems (Headless CMS)

Static Site Generators

SSGs are used to create your static site files. I would have loved to have these when I started designing websites back in 1999! I am sure they existed back then, but these are much more mature than anything last century. I fell in love with Hugo. Hugo uses the Go Templating Language to help you make powerful templates you can combine with your Markdown. Hugo is fast and Go is cool, so I instantly became a fan-boy. But there are tons of choices out there. This is a growing market so don’t stop at Hugo investigate some of the ones listed below.

  • React… Gatsby and Next
  • Vue… Nuxt and Grisdome
  • Python… Pelican and MkDocs
  • Ruby… Jekyll, Middleman, and Nanoc
  • Go… HUGO and InkPaper
  • .Net… Wyam and Pretzel

Gatsby.js is being used by Node.js to update their website. I would suggest following their regular YouTube post about this or join the working group and help. We (Node.js) could always use more contributors. This would be a good way to see professionals using an SSG and maybe learn a few things.

PLUG for Node.js…
*Get caught up on the
“Working Groups – website redesign” videos
*You can contribute to the
Github repo

Jekyll is another SSG I would suggest based on the size of the community. I don’t currently use, or know Ruby, but I hear there are a ton of plugins to do whatever you might need. If you run into a problem Ruby is a popular language and I am sure you could find some great help if you asked.

The pros and cons of SSGs

Pros

  • Fast page load times
  • Security and reliability (shrinks your attack surface)
  • Flexible

Cons

  • Content management
  • Administrative tasks
  • Dynamic features

Hosting Services or CDN or ADN ( Application Delivery Network )

With static html files you can deploy your site to a CDN “Content Delivery Network” easily. Here I will be covering hosting services, mainly Netlify. I only had a limited amount time to investigate the JAMstack so I made decisions based on ease of use. I tried to use Contentful and ran into some road blocks. I don’t know if it was them or me but because of the problems, I had to move on. Netlify worked like a dream. I watched a few videos then I was off and running. Good job Netlify, you should thank SnipCart for making you look so good.

Using Netlify was as easy as turning my Hugo folder into a git repository. I uploaded my files to Github then Netlify took over. With a free trial I was able to host a Github repo (here). I used the Hugo theme “Terminal” because it looked fun. The site is deployed here.

There are some gotchas. The main one is read the documentation. Netlify cares about the file structure of your site and if anything is missing it will fail to deploy. The other main issue I ran into was deploying the site with the theme. I don’t use git submodules and didn’t realize there are special considerations when deploying a git repo inside another git repo, hence the name “submodule” LOL. After combing through some errors, I had to nuke the Terminal theme and re-add it as a submodule. After that it was smooth sailing. Netlify is taking some getting used too because I have a habit of uploading my changes to github immediately even if the code is not working. If you are like me, but don’t want to break your site because you uploaded some “code in progress” I suggest changing your setting or locking the deploy to the last known working commit.

Netlify is considers itself an ADN “Application Delivery Network”. Other Hosting Services that came up in my research were Github pages and Zeit. Zeit has the creator of Mongoose on its team so I will be looking into them seriously when I have time. Mongoose is used to create schemas for MongoDB and I love it.

Postman

I don’t think I have to say much about Postman but if you don’t know what it is then I suggest you get educated. Postman is a tool to aid you in working with REST APIs. It is not necessary, but it simplifies a lot of the abstraction and work needed to test REST APIs.

I would say the API part of the JAMstack is the most problematic. I am so used to calling my APIs from JavaScript, but that kind of goes against the “philosophy” of JAMstack. Once your quote on quote “static website” makes API calls it is kind of not a JAMstack site.

The real paradox is!

It probably is still JAMstack if you use API calls from the site??!!? I know it “bakes my noodle” too. I suggest listening to Coding Blocks and hearing some professionals banter back and forth about it (podcast episode found here).

Go Template Language

I don’t know Go, but now I want to learn it. Hugo is written in Go. Being on a windows machine I had to download the executable to get Go running. If you are on a Mac, then the world of Go should be much easier for you. I assume that Go is the reason Hugo builds pages so fast. I have had an ongoing conversation with Go fans that I meet in SF. People seem to like Go and advocate hard for it. I only hear about Go being used for Kubernetes and servers. The Go templating language was the first time I saw Go in my realm, small/solo developer coding realm. It was easy to follow, given that I haven’t studied it yet. Plus, I like the way it looks in the markdown files. I am all for Go and plan on adding it to my list of languages to study soon.

JavaScript

I don’t know Go, but now I want to learn it. Hugo is written in Go. Being on a windows machine I had to download the executable to get Go running. If you are on a Mac, then the world of Go should be much easier for you. I assume that Go is the reason Hugo builds pages so fast. I have had an ongoing conversation with Go fans that I meet in SF. People seem to like Go and advocate hard for it. I only hear about Go being used for Kubernetes and servers. The Go templating language was the first time I saw Go in my realm, small/solo developer coding realm. It was easy to follow, given that I haven’t studied it yet. Plus, I like the way it looks in the markdown files. I am all for Go and plan on adding it to my list of languages to study soon.

GraphQL

I don’t know GraphQL. I need to learn GraphQL. But I suggest trying to use GraphQL because it will allow you to decouple your front end from the API implementation. Think of it like an abstraction layer to your data. I don’t see anyone talking about this yet with JAMstack but Francesca Guiducci (Twitter @engfragui) gave a great talk at SFNode about GraphQL and the benefits of using it this way. Again, this is on my short list of things to get educated and up to speed on.

Headless CMS

We are at the end of the article. If you like the JAMstack but are stressed because your site is in a CMS like WordPress don’t worry. There are ways to access your old data and move forward with the JAMstack anyway. I suggest you use the Headless CMS solution if you know you want to migrate to the JAMstack but you don’t have time to re-write everything the JAMstack-way. A headless CMS will allow RESTful API access to WordPress or another CMS. Benefits of Headless CMS are:

  • Manage user permissions
  • Manage editor roles
  • Manage content

Now where do you go from here? Share your story. JAMstack is newer and needs more people sharing their journeys.

My Dojo, the way of the coder

(What is BJD?)

Berkeley JavaScript Dojo (“BJD” for short) is a developer community in Berkeley California. I created it as a space for developers to gather and share knowledge around JavaScript frameworks, libraries, best practices, etc. I encourage folks in the community to ask for help, share their expertise, and generally help others code better. This is a safe space for anyone from novice to expert.

(How does it work?)

BJD has a short event each month where we get together in person, with our computers. This event is normally held on the weekend (Saturday), during the day (Noon). Since I work full time Monday thru Friday weekends are easier for me to schedule an event on. The weekend event helps me keep a better work / life balance.

The goal of a monthly real-life event is to get to know each other. It is much quicker and easier to share information in person. If we all have our computers then we can try things out live on our own machine, aka in our Dev Environment. If we run into issues while coding, we can bring them up on the spot. With all the developers in the room from various backgrounds we can usually figure it out. For example, I work on a Windows machine and most of my friends have Macs. This usually means we have different steps to make examples work. Meeting in real-life helps limit potential frustrations that come along with “trying” something out.

Once you come to our meetup you get an invite to join our Slack channel. This gives us a way to keep up communications during and after the event. I also think it is a great way to network with folks in the area.

BJD also has a Github repo for developers to work from or add to. The repo has an eastern philosophy theme, but the core practices described in the repo are universal to all coding. The repo is open source so anyone can fork it or make a pull request.

(Why a JS Dojo?)

BJD was created with my love of martial arts in mind. The core purpose of BJD is to practice coding every day we can. It is hard to code every day, but to set a goal with this philosophy in mind isn’t. I also wanted to make BJD fun and interactive. Martial artist should practice every day to maintain their art and improve. The artist who practice every day should improve, over time. How long should a participant practice? I leave that up to the individual. What I do know is that working to code on deadlines should not be considered practice. Practice is a space where we are allowed to experiment and make mistakes without the pressure of possibly losing our job or our clients. Within the “practice” lies the potential for growth.

One day in 2016 I made a connection between Martial Arts and Coding Practice. Once I started with this analogy, I went all the way down the rabbit hole. The way of the warrior and the way of the coder are different points on the same bridge.

The “Dao of BJD” is to become a sifu. A sifu is traditionally a skilled practitioner, or teacher, or even master of their art.

How do you become a sifu in BJD?

You start by going to a Dojo, join an event and show up for the real-life meetup. Once at the meetup you can meet other sifus. Ask questions or share your knowledge.  Once you are in the Dojo you will be invited to join our Slack Channel. The head sifu of the dojo can be referred to as “Root” or “Sifu Root” followed by their dojo name. This is purely for fun. No one is actually required to use different names in, or out, of the Dojo. I ask all who are serious about the practice to create a “sifu name”. This name is how we will refer to you in code if you want. The name that is chosen must be recorded in the github “Yatate” folder. This is usually the first pull request a sifu will make when they join BJD. The yatate file will have public contact details for you. Similar to the npx business card that Tierney talked about on Twitter.

If a sifu is looking for something to practice, there is a “Katas” folder to browse for inspiration. In the Katas folder are topics divided by language, library, or style. For example you want to get stronger with Github but don’t know where to start I suggest looking at the “Github-katas.md” file for some suggestions. Each kata is given a “Position #” for easier reference. If you get stuck on the kata you can find solutions, or hints in the corresponding “Github-guide.md” file. The kata file has “no code” just challenges. The guide file has code that should be easy enough to copy and paste as a solution.

If Katas are not enough and you need a challenge, I recommend trying to get a Dojo “Belt”. Katas are a form of practice used in martial arts. A kata will usually combine many smaller techniques into one Kata. Once a martial arts practitioner has mastered a kata they can try to attain a belt signifying their level of expertise. I do a similar thing in the dojo. Sifus are allowed to gain belt ranks. The belts are designed to show a level of commitment more than a level of competency.

From White Belt to Black belt

Some sifus seek extreme challenges. We have a “Koans” folder of coding riddles which are like developer interview questions. These are intentionally hard coding challenges. The best Koan will break down the developers pre/mis-conceptions about programming. Then through discovering a solution it should help them progress because they no longer see a challenge but a new way of thinking when faced with that same type of situation.

Putting all the little kata practices together is important. For this we have a “Wuxia” folder which is comprised of tasks. These tasks are usually so legendary that they can be accomplished in any language. For example, build a website would be a Wuxia level challenge. It is something you should know how to do in JavaScript.

In the real world Sifus work on “Projects” so there is a folder for that. A place where sifus create projects that other sifus can work on too.

(Where is the dojo?)

The Dojo is in our hearts and minds… My goal for the Berkeley JavaScript Dojo is to have others take the concept and make it their own. I would love to see a Miami JavaScript Dojo, a London Dojo, an “anywhere” Dojo. This idea was meant to be forked and expanded on. Just like the martial art schools I expect that someone will like it so much that they take it with them where they go and plant the seed in a new part of the world. Bruce Lee did this with his Jeet Kune Do (JKD) and my dream would be to have this happen to BJD.

(When is BJD?)

Practice when you have time. If you don’t have time. Take the time. Make space in your schedule while commuting or waiting in the lobby to code for a few minutes. Run through a kata. You could also schedule to be at one of the monthly events, or pair up with someone on slack if you need motivation.

(Who can participate in BJD?)

As long as you have a computer to work on you are invited to the Dojo. We are creating a collaborative space so it is crucial that you can participate if you show up. It is also crucial that we respect each other in our actions, voices, and code. We follow the JS Conf code of conduct for this purpose.

Spread the word and help us out

Node.js!? Why use it?

Know your why! Avoid making blind coding choices.

TL;DR
Node.js is fast.
It allows a company to hire only JavaScript engineers.
It can work on multiple platforms, other than the web.

When first introduced to Node.js in 2014 I was shocked by what I was seeing. Ward Bell was giving a demo of Node.js, ExpressJS, and Jade. Jade has since been renamed to “pug”. Node.js surprised me because it was easy to set up a web server. In my experience with Microsoft technology it was never that easy. The web server came with “software bloat”. Plus developers had to buy a license for Windows Server to run “Internet Information Services” (IIS). Contrast that with a Node.js web server that can be set up with as little as five ( 5 ) lines of code.

When Ward was done with the entire demo, I was still wondering how he got a web server running in JavaScript. This server didn’t have any security. I wouldn’t say it was ready for enterprise environments, but on a software development machine this was less of a hassle than I was used to. Node.js was about to change my world, and I knew it.

Later I found that the web server he used, ExpressJS, was only the tip of the JavaScript iceberg. Node.js has so many features and benefits. One benefit is how lightweight it is. Node.js version 10.13 is only a 15 MB download. Compare that to Windows Server 2016 at 32 GB.

Node.js lends itself to being highly customizable. The initial application has basic functionality and then you add what you need. Even the ExpressJS web server that I mentioned before can be substituted for another web server package depending on your preference. ( Hapi, Koa, Meteor, Socket.io, Sails, etc.)

JavaScript has so many software packages and choices available that one can get overwhelmed. It is often called “JavaScript Fatigue”. To overcome this, I turned to the internet. I found many JavaScript communities online, some in my own city, and I even created one here in Berkeley (BJD). I love the JavaScript community! After developing software alone in the “Hinterlands” it was refreshing to discover how open the JavaScript community is. I feel the community at large is comprised of welcoming groups of engineers and hobbyist, looking for other likeminded souls. I think there is a bit of a positive feedback loop happening because everyone benefits from the “mostly” open source code. The support from the community is not limited to Node.js.

Community and support are huge benefits but Node.js has some essential winning characteristics. These are results that you can show off.

1. “Node.js is fast.”
Node.js is built for the web, it is designed to work like the web does. Node’s asynchronous behavior can handle the many data packets being transmitted all over the place. Node.js accepts all those network requests, never stopping the flow of data. Once the request is completed the response gets routed back to the sender. Basically the web user’s multiple clicks are recorded and served when done. Some requests are completed faster than others, but all get worked on and no one is turned away.

2. “Enables Full Stack JavaScript”
No company wants to spend more money than they have too. I think the hidden beauty of Node.js for business is the ability to hire engineers who know one language. What does that mean? For example, companies would traditionally hire a Linux engineer for the back-end servers, then a database engineer, then a front-end engineer for the website. Those engineers are specialized experts in what they do, but they aren’t always busy at the same time. Each engineer gets paid whether they are busy, or not.

“What If?…” the same company could hire engineers who specialized in JavaScript? In the same business example they hire one engineering language. Those engineers can design and setup the back-end servers, created in Node.js. Then work on the database, created in MongoDB. Then finally work on the front end, created in AngularJS. Now the business has hired all JavaScript, making it more agile. It is easier to move engineering resources around as needed.

All businesses go through project phases. When the company doesn’t need 40+ hours of your time what do they do? The answer is simple if they are a full stack JavaScript company. You can move engineers around to fit the your needs. Designers can become maintainers (fixing code bugs), or develop new code features, or even work on refactoring the original code for efficiency. The possibilities are endless with Node.js as the back end, and JavaScript everywhere.

3. “Cross-platform development”
The Holy Grail is that Node.js isn’t only for the web/internet. It can also be used to develop desktop applications. Did you know Slack was written in Node.js using Electron. What!! Yes! JavaScript is winning by making every engineer as useful as they want to be. Does this mean that JavaScript is perfect? No. I suggest using Node.js as the business defines it’s needs and figures out the “pain points”. Then look at refining the product to address those issues. If you need more speed you might have to find another language or product. If you have a choice Node.js is the way to go, it even works for NASA (Github).

Node.js is just fine. Let’s say it is the “goldilocks” of software development. Not too much, but enough to get the job done. How can you get that idea off the drawing board (Pitch Deck) and into a workable demo (MVP) that is ready for the market ($ales)?… I suggest using Node.js.

Helping neighbors with chickens

#FutureGenerations #NextStep #SaveThePlanet

I want to take more steps towards rebuilding the Earth’s ecosystem. Today inspiration hit me. Caring community is what will save us.

In this small urban space with only concrete as our backyard what can the Tepper-Grisby household do to make a difference. Reduce, Reuse, Recycle is the motto of this grotto.

While researching worm composting I realized that we might be able to do a little more. From my experience composting in any form takes time. We buy more fruit and vegetables in a week then the worms could eat. What would our household do with the rest of the organic waste so it doesn’t go into the trash ( landfill ).

If you have ideas please share in the comments.?

For those who have chickens, would it sound “cooky” to have a neighbor ask you “What do your chickens like to eat?”. I want to ask our neighbors who have chickens if we could give them some of our organic waste in an attempt to feed their livestock and reduce the amount of trash we put in the landfill.

I would also like to hear any suggestions you have about what chickens need that you don’t ever have enough of.

I’ll stop there. That is enough for one post.

Avoid avocado skin and seed/pit.

 

Website resource of foods for urban chickens

security-README file, “SECURITY.md”

“Security is not about speed but finding help when there is a security issue should be.”

The “tl;dr”Security readme file has the project’s “security policy” and “vulnerability reporting” (A.K.A – “responsible security disclosure policy”) in a separate file. The security readme file is in the root directory of an open source project. Security readme files for open source repositories should be a new guideline.

I am asking the JavaScript ecosystem to use a “SECURITY.md” (also referred to as a “security readme file”) to their repositories. My goal is to improve open source security by making policies more accessible and reporting security vulnerabilities easier for everyone.

This isn’t a new thought! While giving a talk at SFNode about “Node.js Security best practices” I realized “security.txt” functions in a similar way. Unfortunately, the “security.txt” file is not intended for humans to read. This is a standard for websites and servers to use in the wild ( A.K.A – the intra/internet ). BUT the idea is the same, provide a route for contributors to report a security issue easily.

Thank you to Rich Trott of Node.js for taking my talking point and running with it. I also want to take a moment to thank these other projects for already using security readme files (SECURITY.md).

Visit my GitHub repository “security-README”. I welcome comments to this idea so we can make the open source community a better place than we found it.

Please help me:

  1. Star this GitHub repo
    ( https://github.com/Trewaters/security-README )
  2. Star this GitHub repo
    https://github.com/Trewaters/SFNode-Nov-2018 )
  3. Follow me “@trewaters” on GitHub
     ( https://github.com/Trewaters )
  4. Follow me on Twitter
    https://twitter.com/trewaters )

SFNode Meetup, Nov 2018 talk

Thursday, November 1st, 2018

I ( Tre’ Grisby ) talked at a SFNode Meetup. The meetup was hosted by Quantcast in San Francisco, California. Quantcast was a great host and had one of the best receptions. I want to give a big thanks to Quantcast for being such gracious host!

My talk was titled “Node.js Security, best practices“. It was a top ten list of security practices that are beneficial for anyone getting started in node. The goal was to identify possible threats and tools a developer could use to minimize exposure to these threats.

I will not write out all my notes again here. Below is a link to all the resources I used in the talk.

security.md

As part of my talk I introduced a thought. In the pursuit of making security more accessible, and reporting vulnerabilities easier. I  asked the JavaScript open source ecosystem to start using a “security.md” file in github repositories. ( Read more here… )

The tl;dr is… adding this file to the root directory should be a new standard. This file will have the project’s “security policy” and “vulnerability reporting expectations”. This way anyone that wants to report an issue can do so easily. This is modeled on the “security.txt” file. Check out my github repo and make comments to help me improve this proposed standard.

Please help me:

  1. Star this github repo
    https://github.com/Trewaters/SFNode-Nov-2018 )
  2. Follow me “@trewaters” on github
    https://github.com/Trewaters )
  3. Follow me on Twitter
    https://twitter.com/trewaters )

Tutorial Review of Scotch.io

Tutorial Review
Setting Up a MEAN Stack Single Page Application

I will review a MEAN Tutorial I found on Scotch.io. All mileage will vary. In order to learn code I like to do a little reading then dive into a tutorial. I can’t learn everything I need to know by reading. Computers are so complex I find it is better for me to dive in and start pecking away at the keyboard. By creating and fixing my own bugs I start to understand what is going on with the code.

I picked the MEAN stack because I know how to use MongoDB and wanted a full stack that would let me develop with MongoDB in a real-world way. I picked this tutorial by trial and error. I started a few tutorials but this one I could actually finish. The MEAN Stack is a popular choice for developing with javascript. The MEAN stack is an acronym for MongoDB, Expressjs, Angularjs, and Nodejs. Stack refers to the fact that this will cover the backend, middleware, and front end of your application.

I will only review the tutorials that I believe are helpful and this was one of them. Scotch.io walked me through a reasonable set of task that allowed me to have a full working application when I was done. That is a big plus. Some of these tutorials are not explicit enough for you to walk away with anything, but this one doesn’t fall into that trap. Plus if you want to take it to the next level they have more tutorials that share MEAN tricks they have learned since making this tutorial.

Try this tutorial at found at setting-up-a-mean-stack-single-page-application

Learning Developer Tools

For the first half of 2015 I have been learning new software technologies. Each new language, framework, or application is a tool to add to my development tool belt. Learning new technologies has been a commitment. I have a full-time job and family. I work hard to get 10 hours a week of software coding done. Learning something new takes all of that 10 hours.

Why add tools to my tool belt?

Software development is an ever changing environment. When I worked 10 years for the water/sewer district. I didn’t have to really push myself to learn anything new. They hired me 6 months out of school for what I already knew. Our stable business didn’t need breaking new technology to run. We had our business technologies that didn’t need to change often. You could pretty much do the same thing with a few upgrades for decades and it would be fine. I grew stagnant. I didn’t realize it until I moved to the San Francisco Bay Area with my family.

Job hunting with a 10 year old skill set made it daunting to look for and expect to find a decent job. Getting a job isn’t the issue. I want a dream job. I want to code software that the world uses. The only way to get that dream job is to learn some of the new technologies.

MongoDB started the path. I grew up with Microsoft SQL and structured databases. I enjoy structured databases and was intrigued at the idea of a NoSQL database. It sounded “cool”, it looked great and to my surprise it worked amazingly. All of a sudden using MongoDB freed me of decade old SQL bondage. The chains of conventional databases fell from wrist as I explored the capabilities of this new technology.

Learning and using are not the same thing…

While I learn something new and do tutorials I find that I get little time to really practice with the technology. It is important to use what you know or you lose it. I had to find a way to incorporate MongoDB into something I could develop. I learn by doing not just reading. Well that thought led me to the MEAN stack. MongoDB is used with Express.js, Angular.js and Node.js. If I want to use MongoDB in a real world way I need to be able to programatically add and remove data. MEAN allows me to do that but it meant that I should learn more stuff.

Now 6 months later I am finally at a point that I can start practicing and I am excited.

May the programming begin, in earnest!

Hello World!

Hi,

I have been a DBA for the past 10 years. I had a successful career with a water and sewer utility district managing everything from IT to DBA to some Microsoft Visual Basic for Application projects.

I did it all for this small company and I felt good about my work. BUT I was not quite satisfied. By filling the role of General Technologist for the utility company I turned my back on my roots. For me the root of my passion was software development. It’s what got me started so long ago and what I really loved working on in my professional career.

This blog will be a journal of what I am doing and how I have decided to change my career path mid-stream (middle age) back to its roots.

Hopefully following my exploits will help you along your journey…