Category Archives: Blog

Post in the Dev Mind Blog

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.

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…