Why?

Manual Work

It’s becoming more of a hassle to publish my content in multiple places on the internet, especially since the content isn’t easily exportable from my website into a format that works well with Medium. I often have to spend a lot of time properly formatting the blog posts that I’ve already written, so it makes for a decent amount of extra work.

Low Engagement

Compared to the Dev Community, the articles I post on Medium don’t get viewed all that much and people usually don’t post as many comments on Medium. I love engaging with an audience related to the content I write, and Medium hasn’t been all that fruitful in that regard.

I should remark that I have received a lot of views when I published my articles for large tech publications on Medium. However, the review process to get articles published can be long and laborious. I’d rather publish content on my own timeline.

Syntax Highlighting

This is a major grippe for me. Medium hasn’t implemented support for syntax highlighting of code blocks, even though there is a huge community of developers that use the platform. I know that this has been a very widely requested feature and it’s disappointing that they still haven’t implemented it within their platform.

Anyways, if you want to stay up-to-date regarding my latest dev articles, you can subscribe to the RSS feed for my website, follow me on Twitter, or follow me at the Dev Community.

✌🏻

Originally posted on my blog

I’ve decided to redo my website, yet again. This is the 3rd or 4th iteration of my website.

Here were the motivations and goals for the redesign:

1. Host my blog articles on my own website

I’ve been writting a lot on both Medium and a bit on Dev Community, but I want to have a bit more control in the design and presentation of my blog posts. One of my biggest gripes with Medium is the lack of syntax highlighting for code blocks.

2. Better highlight past projects

In 2019, I want to work with a few clients on a part-time basis to supplement the income I make through my full-time job. The first step to doing that was to make sure I can showcase some of my past work in a favorable light.

3. New tech stack

My previous website was using gulp to build HTML pages from templated pug files. This wasn’t that bad since I only had one page on the website, so there wasn’t a need to move between pages. However, now that I was going to include a blog, I was going to have to have multiple pages on the website and thus I wanted to use React to get the performance associated with a single page application.

Design

So with those three goals in mind I started to research blogs that I admired. I made sure to screenshot and anotate any elements that stood out to me. I gathered all those screenshots in my design app of choice: Figma.

After I gathered all the pieces of inspiration, I went ahead and designed my own website. I knew I wanted to have both a light and dark theme to my website, so I made sure to design both variations.

The reason why I create design mockups instead of just coding the site straight away is so that I can quickly test out which designs look good. I find that I end up doing a few design interations before coming up with a final design. Doing those different variations in code rather than in a design software would take much longer. I also find it helps me better organize my work when I design the project before going into the code, and it ultimately saves me time.

Home Page

The home page, being the first place site visitors land when they visit my site, includes a short description of who I am, the blog articles I’ve recently written, as well as a preview of the recent projects I’ve worked on. I made sure to animate elements on the page, using the animate on scroll library, to make the experience slightly more enjoyable.

I’ve included a headshot of myself and I tried to crop out all of the background from the image. Unfortunately, I don’t have the design skills required to get rid of some of the white background from my hair and it is prooving to be quite the annoyance every time I see it.

Projects

I’ve created a page to better showcase my past projects. Each app is presented in a similar way, with screenshots of the apps found within desktop/mobile device frames. Each project is also given it’s own section with a short description along with keywords indicating the main technologies used for the projects. A call to action section is found at the bottom of the page for any visitors interested in working together on a project.

In the future, I plan to create full pages for each project in order to present them as full blown case studies.

Blog

The blog is where things get exciting technology wise. The website is built with React and Gatsby. I’m also using gatsby-mdx which allows me to write my blog posts using MDX. MDX is a different flavour of Markdown which allows for the use of JSX and React components to coexist with markdown in the same file.

If I want to include a custom React component into a blog post to make the post more interactive, I can now do that in MDX. As an example, I can embed the theme switcher component I’m using for my website right into this post:

See article on my website for the embed React component.

I’m quite excited to take advantage of the power of MDX in some of my future blog articles.

Another feature I’ve added to my blog is the horizontal progress bar indicating a user’s progress through a blog post. I’ve seen this UI pattern on some other blogs and have enjoyed it myself.

I’ve also include a comment section to blog posts using the Disqus embed. This was surprisingly easy to incorporate into the website using disqus-react.

Dark / Light Theme

Perhaps my favourite part of the website is the ability to toggle between a dark and light themes. I’m using Styled Components to manage the styles on my website and it fortunately has great a API for managing theming.

I’d like to point out that the design and functionality of the theme toggle switch was all taken from @thekitze’s Twizzy App landing page. I’m always thankful when talented people like this make their projects open source to allow others to benefit.

I hope to continue to make incremental improvements to my website. Some of the things I’d like to add include unit testing, end to end testing, and an RSS feed to the website. There are also a few bugs I need to squash 👞🐜.

View the source code

I recently got my first iPhone app accepted into the Apple App Store. It is quite exciting to be able to have a product i’ve been working on by myself now available for a whole bunch of people to download. I tried to use a structured approach for the whole app creation/release process and I’ve outline that process in this article.

Motivation

Why did I want to build an iOS app in the first place? Well, I like building out things that could be of use to myself and others. Creating an app downloadable from the App Store makes it very easy for others to get the app on their phone and start using it. I have a bit of experience working with React Native at one of my previous jobs, so I was confident I could build the app myself.

There is also the possibility for me to generate some passive income with iOS apps, if I choose to monetize the app. I realize that the majority of apps in the app store make very little, so this is by no means my primary objective.

App Idea

I wanted to build an app that I would want to use, but that others would also want to use. I also, didn’t want to create something that already exists since I wanted to provide a unique solution to a problem. A lot of developers create games for the App Store, but I did not want to do that since I don’t play games on my iPhone and I find that games generally don’t positively impact a person when they play them.

I’m someone that’s interested in keeping up-to-date with the latest in health, nutrition, and performance, and I’ve noticed a dieting trend called the carnivore diet, that a lot of people have been benefiting from. Out of curiosity, I decided to try the diet, and I quite enjoy it, so I’ve stuck with it so far. The diet only allows for meat products to be eaten.

Since the carnivore diet is something that is a fairly recent phenomena, there weren’t any apps catered towards the diet and so I thought that might be a good void to fill. I got the idea of creating a food journalling app that would only allow for the addition of meat as food entries.

Planning

Once I decided what my iOS app would be about, I wrote a summary of what I wanted the app to do so that I could keep it in mind while looking at features to add. Here’s what I came up with:

An application to record entries of the meat eaten during the day. Targeted towards those following a carnivore diet. The app is simple and doesn’t include calories because people on the carnivore diet just eat until they are full. The app is a way to journal the amount of food eaten. A simple app with no extra fluff.

Notice the emphasis I put on keeping the app simple. Since this was my first mobile app, I wanted to make sure I didn’t make things too complicated for myself. Had I envisioned a feature-rich application, I know I would likely get discouraged and potentially give up on the entire project.

Once I had a better idea of what I wanted to build, I started to list out the features I’d like to have in the app. I categorized things under V1 and V2, where V1 are features that should be part of the first version of the app and V2 would be features that would be cool to have in a future release.

Design

I care greatly for the user interface of applications as I believe it makes an application more enjoyable to use when the application looks good. For my application, I made sure to look at the design of other mobile apps for inspiration on how I wanted my app to look. I collected screenshots of some apps I had on my phone as well as designs I found on dribbble, and combined them all into a document. In the document, I made notes on the UI elements I liked and how a similar design might fit in with my app.

After I had gathered some inspiration for the UI, I sketched out wireframes for the screens I would need in the app. I did this by hand and then uploaded images of the sketches to Figma, the design app I use.

Next up, I started building out high fidelity designs for the application. I did this all in Figma, and you can actually view the designs for yourself. I took all the icons from FlatIcon and made sure to pay for the rights to use them.

Development

I decided to use React Native for the app as I already had experience with it and did not want to learn a new programming language. I also decided I would only focus on developing for iOS, even though React Native also allows you to build for Android. The decision to only focus on iOS is because making everything work exactly as intended on both iOS and Android takes a lot of work. Just because something works on iOS, doesn’t mean it will work on Android. Also, since I own an iPhone and not an Android it made sense to develop on iOS as I could test the app in both a simulator and physical device.

I used a React Native boilerplate to quickly get up and running with the app development process. The boilerplate includes TypeScript and MobX, which was really nice to work with. I had never used MobX prior to this project, but I really enjoyed using it to manage the global application state.

I also setup the project with continuous integration/deployment with Visual Studio App Centre so that every commit I made to my master branch would build the app and deploy it to Itunes Connect. Itunes Connect is where you can submit your app to the App Store as well as conduct using testing with TestFlight.

I chose Visual Studio App Centre for the CI/CD of the project because their free tier was able to accommodate all of my needs with 240 minutes of build time per month with a max build time of 30 minutes per build. I wanted to use Circle CI, but their free plan doesn’t allow for builds on MacOS machines, which is required for iOS. I also considered using Bitrise since their UI/UX is really nice, but their max build time is 10 minutes per build and my builds were taking just over 10 minutes to complete.

User Testing

Apple has their own user testing app called TestFlight, which allows you to invite others to download and test an app before it gets released to the app store. I didn’t really have a good pool of trustworthy and interested people to test my app, but I did manage to get two of my friends to download my app through TestFlight. User testing of my app wasn’t really a priority for me as I did not have high expectations for the app.

Where I did end up getting a lot of feedback for my app was at a local UI/UX feedback meetup I attended. I presented my app to a crowd of people who then provided feedback on how the app could be improved along with potential features I might want to add to the app. A lot of people were interested in the app, but I think it’s mainly because the carnivore diet seems so strange.

App Store Submission

Before submitting to the app store, I made sure to read the App Store Review Guidelines to make sure I didn’t miss anything that I should have done. There is a section of the submission form where you can include notes for the App Reviewers, and I made sure to leave a detailed description of what exactly the app should be able to do. I’ve heard that this gives the Apple reviewers more confidence in your app and reduces the likelihood of your app being rejected.

Also, I made sure to put effort into the screenshots I submitted with the app, as those act as the initial impression of the app for those viewing the app in the App Store. I followed a typically design trend for the screenshots, where you include a screenshot of the app inside of the frame of an iPhone, with an accompanying short description.

After I submitted my app for approval, I got an email less than 24 hours later saying that my app was approved, and a few hours later my app could be found in the App Store!

Summary

From idea to release, the entire process took me a month. Also, in terms of cost, I spent $136 CAD for the Apple Developer License and $15 CAD for the rights of the icons I used in the app. So in total, I spent $151 CAD (approx. $117 USD) on the app. The Apple Developer License is good for 1 year, after which I would have to renew the license.

What’s Next

I’ll continue using the app myself and see if there are other features I want to add to the app. I’ll monitor the number of downloads of the app and gather any feedback from users to see if it’s worth investing more time into further developing the app. I quite enjoyed the entire experience so I may even try to develop more apps for the app store.

From Idea to App Store: Building My First iOS App With React Native was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ya, I deleted Facebook and Instagram. No, i’m not better than everyone else because I did so. I just wasn’t getting any value from both platforms and wasn’t enjoying the things I was reading and seeing on both apps.

Facebook

Looking at my Facebook feed, I saw posts related to people’s political views, pictures of pets, random status updates on people’s lives, videos of people doing epic fails, etc. None of that stuff really interested me. If I want to know more about what one of my friends is up to, I’d rather just message or call them.

Also, I’m not a huge fan of having likes associated with posts. It almost feels like some sort of fail when your post doesn’t get a good number of likes. Who the hell I was trying to impress, I do not know. I also felt as though other people might not like me as much if I didn’t make an effort to interact with their content on the platform. I know, I sound like a crazy person.

I ended up using a Chrome extension that completely blocks anything from showing up on my newsfeed. I also deleted Facebook from my phone, so I was no longer looking through my Facebook newsfeed. This was actually a nice improvement to my social media experience, as I was spending less time on Facebook because of this. However, I was still making the occasional post myself and with posting comes likes and comments. I found myself frequently checking Facebook just to see if I got more likes on my post or to see if anyone commented on my stuff 😐.

It seemed strange for me to not consume any content from others on Facebook, but I was still posting stuff myself for others to look at. The only thing I was doing in the app was posting the occasional life update as well messaging people.

After doing a bit of research, I found out you could still use Facebook messenger if you deleted your Facebook account, so I ended up deleting my Facebook account. Before I deleted my account, I made sure to download all my data so I could keep the pictures and videos I uploaded to the platform.

Instagram

Even after deleting my Facebook account, I kept Instagram on my phone for a bit. After all, it’s just your friends sharing pictures, right? Well, I opted to eventually delete Instagram as well.

I found myself browsing Instagram like I use to browse my Facebook feed. I would also often go into the discover tab to find stupid videos I couldn’t stop watching. Instagram has the same problem for me with their like system which often leads to comparing my posts with other people’s. When I was posting my pictures, I didn’t feel as though I was really appreciating the picture I took and the memories associated with it. There was always that lingering thought of how others would react.

So ya, I downloaded all of my Instagram data and GTFO’ed.

What Now

I bought a cabin in Tasmania and I am now planning to live the rest of my days there, feeding off wild game. Ok, that’s a lie. I’m still using social media in the form of LinkedIn & Twitter. I’m also working on completely redoing my website and I’m hoping to have a Life Updates page where I can post some of my favourite pictures that I take as well as keep a record of some of my major life milestones.

In the past few months I’ve been doing work with React Native, which is a change of pace from the React web apps I was more familiar with developing. Now that i’ve gained experience with React Native, I’m going to explain a bit how React Native differs from React for the web, and what to expect when developing with React Native.

React

Let’s first briefly talk about React. React is a JavaScript library used for building user interfaces. It was initially released by Facebook in 2013. React uses a concept of a Virtual DOM to represent how your UI should look like while the state of your application changes.

React Native

React Native is a mobile framework used to build out mobile apps with JavaScript. It, unsurprisingly, uses the React library to construct the UI components as well as define an application’s business logic. It was initially released, again by Facebook, in 2015. One novel feature React Native development provides that standard native development doesn’t is its live reload feature that can quickly re-compile and serve a bundled javascript file after making changes in the code. This feature has been available on the web for some time, but in the mobile development sphere, it was a new concept.

Similarities

Both use…React!

Both the UIs for apps built with React on the web and React Native will have the same general JavaScript structure with props , state , and all the standard React component lifecycle methods. You can use the same state management libraries (e.g. Redux) in React Native as you would for React on the web.

JSX

React Native stills uses JSX as the templating language in the component’s render method to define the UI. Although the base components used in React Native aren’t DOM elements, like <div>, you still use the same syntax since it’s all JSX.

Browser Debugging

The JavaScript code in React Native usually gets parsed on a device’s JavaScript engine, called the JavaScript Core. However, if you enable debug mode on a mobile simulator, you will be able to run the JavaScript through a browser’s JS engine and you will therefore have access to tools such as the Chrome debugging tools. This allows you to use console.log() statements and read the output in a browser’s console. You can also inspect XHR requests being made and if you’re using Redux, you can take advantage of the Redux Devtools as well.

package.json

JavaScript dependencies can all be managed with yarn or npm and you will see all those lovely dependencies tracked in a package.json file. This allows you to take advantage of all the packages NPM has to offer and so popular dependencies such as lodash , date-fns, and immutable can be used in React Native projects. However, any dependency that relies on HTML, SVGs or the browser canvas will not be usable with React Native.

Differences

Base Components

React native comes with a set of built-in components that can be used to render UI elements on the page. These are different than the standard <div>, <p>, <input>, and other DOM elements that are used with React on the web. Some of the React Native built-in components include <Text>, <View>, <TextInput>, and <Image>. There are of course many other and there are also some 3rd party components that can be downloaded from NPM.

Styling

Styling isn’t done with CSS in React Native, however the syntax is quite similar. To apply styles in React Native, a StyleSheet object is created and applied to a component’s style attribute. The property and values used in the StyleSheet object are similar to what you would find in CSS, but the naming uses camelCase and there are also many features missing in the React Native styles that you would otherwise find in regular CSS.

Styling on the web:

Styling on native:

Routing & Navigation

React Native has 2 popular choices for implementing native navigation in an application: React Navigation & React Native Navigation. Really great original names if you ask me. Personally, React Native Navigation is the solution I prefer since it uses the actual native navigation API associated with iOS and Android, whereas React Navigation’s implementation is done purely in JavaScript.

Honestly, incorporating Navigation on Native can be painful when dealing with complex nested routing and styling navigation related elements isn’t always obvious. Routing React web apps is much simpler.

Platform Specific Code

React Native can detect which platform an application is running on (iOS or Android) and serve a different set of code based on that platform. This can either be done by separating React Components into files ending in ios.js and android.js or it can be done using the Platform module that ships with React Native.

JavaScript Runtime

React Native runs its JavaScript through the device’s JavaScript Core, unless the app is running in debug mode, in which case the browser’s JavaScript engine parses the JavaScript.

React Native runs on 2 different threads. The Main thread is responsible for rendering the UI and receiving user gestures while the JavaScript thread is responsible for defining the structure of the UI as well as handling the application’s business logic.

The React Native architecture is quite interesting and you can find many good talks on YouTube from the Facebook developers talking about the inner workings of React Native. Here’s two talks worth checking out if you’re interested in learning more: one, two.

Personal Opinions

Ok, real talk: developing for the web is more pleasant then developing for mobile. React Native doesn’t have as large of a developer community than the the community surrounding web applications, so it isn’t surprising that the tooling isn’t as great for React Native. Debugging code in React Native can be difficult at times which can be the cause of some frustration.

Although React Native is arguably the best tool for cross platform mobile apps, i’m hoping that Progressive Web Applications continue to grow in popularity and will eventually allow for responsive web applications to include native mobile functionality. When that day comes, developers will be able to develop a web application that is responsive, include some native mobile functionalities through browser APIs, and only have to worry about one codebase!

Until then, React Native is a great way to quickly get started with building applications with JavaScript 🚀.

If you found this article interesting and front end development interests you, consider following me on Twitter, Github, or LinkedIn.

Transitioning from React Web to React Native Development was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’m a web developer. I put together the technical components required to make a web application functional. Often times, I’m given designs to follow along with which makes my life easier since I don’t have to put any thought into creating an aesthetically pleasing app. However, that’s not always the case.

There are often times I wish I had some real design skills. For example, whenever I make a new blog post, I’d love to be able to make some killer illustrations to help clarify my topic of discussion. Also, whenever I work on a new side project, I’d like for whatever I create to not look like a pile a crap.

Recently, I got a hold of a Sketch license for work and I decided to take on a side project where I would first create the design using Sketch, and then move on towards implementing the design in the form of a website.

My sister owns a floral design studio and she already has a website she built using SquareSpace. I wanted to take on the challenge of creating a completely new website for her built on Shopify. I’ve built sites with Shopify before and I’m comfortable working with their templating language to build out a custom site.

So I opened up a new blank document in Sketch and got started 👨🏼‍🎨.

Design Phase

The design process took me forever… and I only ended up designing the home page 😐. I went into the design wanting everything to be perfect and I wanted to try to use good design practices. This definitely hindered how quickly I was able to come to a solution.

I made a design for 3 different screen sizes (desktop, tablet, and mobile). I used symbols wherever I thought was appropriate in order to follow a sort of atomic design methodology. I organized and grouped my typography components in a way that allowed for easy changes to sizes, colours, and font family across the design. And on top of that, I installed a handful of plugins to try to make certain things easier like renaming multiple layers and creating flexbox-like responsive layouts.

I struggled with setting up symbols in a way that allowed them to display exactly how I wanted them to look for all cases. For example, I created a tag symbol that allowed the text to be changed as well as the colour to be one of two values.

When I ended up changing the text to something other than the default, I didn’t end up getting what I wanted…

This constant tweaking of symbols took up a lot of time, and I still didn’t get them all setup quite right. Also, I found it quite difficult to maintain the design of the homepage in 3 different screen sizes. As you can imagine, as I changed the look for one screen, I had to change the look for the other two. Also, some of the symbols I used for desktop where too large when I used them on mobile, so I had to maintain two sets of symbols in certain cases.

What I ended up coming up with as a design for the home page is the following (desktop version):

Here’s a zoomed out version of the 3 screen size designs of the same home page:

After spending so much time in Sketch designing the home page I had enough of designing things and ended up going straight to implementing the design and creating the other pages of the site on the fly.

Implementation Phase

I built out the Shopify site using Shopify’s theme development toolkit, Slate. It gives you the bare essentials required to get started with building out a custom theme on Shopify.

Before I started this project, I had envisioned that I would design something in Sketch and then try to replicate the design right down to the pixel on the web. Well, I didn’t end up doing that. The mockup I made in Sketch ended up being a rough guide to how I implemented the design on the web.

In fact, I had to change the design of the home page a bit because the layout I had created in Sketch was too complex to implement in a responsive manner on the web, so I ended up simplifying it.

I deviated a lot from the design as I started adding everything to the site and the final result looks kinda-sorta like the design I made in Sketch.

For the other pages of the website, I looked into other e-commerce sites for some inspiration and I also looked up specific component designs on Dribbble. For example, the contact forms were based off a design I found on Dribbble.

Click here to see the live website if you want to see how I designed the other pages on the site and see some of the animations/transitions I’ve incorporated. Note that my sister did not end up using the Shopify site I designed for her (Shopify has a higher monthly cost than SquareSpace and my redesign didn’t particularly “wow” her). I’ve changed some of the content to be more generic and am keeping the site live for illustration/demo purposes.

Takeaways

If I had to repeat this process I would definitely do some things differently:

Don’t focus on creating high fidelity designs

For my use case, I think it would be more beneficial for me to do more of a wireframe design in Sketch, at least to start off with.

Do more research beforehand

I did most of my research on the fly for how the design of the site should look. I think it would have been more useful had I done more upfront research and then went on to design more pages in Sketch before moving on to implementing the design on the web. It would have made the development process less “fragmented”.

Don’t try to prematurely optimize designs

I wasted a lot of time trying to figure out how to properly used symbols and try to setup Sketch plugins that were suppose to make the design process easier. However, I don’t even have a good grasp of the fundamental tools in Sketch so I haven’t even had the chance to experience most of the pain points these tools were suppose to help resolve. I think I would have benefitted from sticking to the bare essentials while designing because I would have been able to produce designs faster and I would have better understood how more advanced tools can help with common pain points.

Don’t strive for perfection

The more I tried to get something “just right”, the more my progress was impeded. It also takes a lot of time to get the last bit of a design to where you ideally want it. This is a common phenomena represented by the “80/20” rule, where the last 20% of the work will take 80% of the total required time.

I will try to apply what I’ve learn to my next side project and l’m excited to see how my next attempt at the whole design & development process goes.

If you found this article interesting and front end development interests you, consider following me on Twitter, Github, or LinkedIn.

There really is no universally accepted standard for naming colors in web applications, which usually leads to a whole bunch of different implementations. However, having a system for naming colors in projects is important, not only for consistency in the codebase, but it also helps when needing to change the colors in your app.

Since I’ve been working a lot on React projects that use CSS-in-JS as well as other projects that use Sass, I will outline two approaches for each type of app. Both approaches share the same approach, but the syntax is different because JavaScript and Sass are different programming languages (that’s probably pretty obvious, but I said it anyway because i’m shameless).

Also, please note that this is an opinionated guide on how to name colors and I realize that many people prefer other approaches. Like they say: “different strokes for different folks”.

CSS-in-JS

Color variables should live in a colors.js file where a colors object is defined with a bunch of color names as properties and values being defined as a hex/rgba/hsl color.

const colors = {
    bertaBlue: "#4BDAFF",
    black: "#000000",
    bloodBurst: "#FF4B4B",
    bloodOrgan: "#630E10",
    blueSparkle: "#0076FF",
    chickenComb: "#DE2525",
    deepLilac: "#9B59B6",
    heartBeat: "#AA0000",
    mango: "#FFA628",
    nero: "#262626",
    palePurple: "#B089D5",
    schoolBusYellow: "#ffd800",
};

export default colors;

The color names used for the object keys are determined using a color namer app I built called Color Namer. All you need to do is type in the color in hex or rgb format and an associated color name will appear.

Alright, so far we’ve made the names of our colors more memorable by associating their hex or rgb value to a user-friendly name like bloodOrgan. If we were to use those color variables for the styling of our app components, we would run into an issue if we ever wanted to change the colors. We would have to do a global search in our code editor to find the name of the color variable and replace it with another color. We would also have to make sure to only replace the color for the components that needs replacing.

For example, imagine you use the color schoolBusYellow for the background color of all your buttons and the background of you main navbar. Down the line, you need to change the background color of the buttons, but not the background color of your navbar, so you need to find each of your buttons and change their background color. That kind of defeats the purpose of using variables, since variables are suppose to allow you to change their value in one place and have all occurrences of that variable update accordingly.

What’s the solution to this? Well you should have a second level of variable naming that looks like this:

const colors = {
    bertaBlue: "#4BDAFF",
    black: "#000000",
    bloodOrgan: "#630E10",
    mango: "#FFA628",
    nero: "#262626",
    schoolBusYellow: "#ffd800",
};

export default {
    primaryBackground: colors.mango,
    secondaryBackground: colors.bertaBlue,
    primaryText: colors.black,
    secondaryText: colors.nero,
    primaryButtonBackground: colors.bloodOrgan,
    primaryButtonText: colors.schoolBusYellow
};

Now when you use these color variables in your components, you will easily be able to change the colors of all associated components by changing their value in the colors.js file. To use the colors, all you need to do is import colors.js and assign the colors to CSS properties.

import colors from "./colors";

const styles = {
    outerContainer: {
        backgroundColor: colors.primaryBackground,
        padding: "40px"
    },
    innerContainer: {
        backgroundColor: colors.secondaryBackground,
        padding: "20px",
        textAlign: "center"
    },
    title: {
        color: colors.primaryText,
        margin: 0
    },
    subtitle: {
        color: colors.secondaryText,
        marginBottom: 0
    },
    button: {
        backgroundColor: colors.primaryButtonBackground,
        color: colors.primaryButtonText,
        border: "none",
        padding: "10px",
        marginTop: "20px",
        textTransform: "uppercase"
    }
};

Here’s a demo of this would look like in a React application:

The above example uses inline styling for the components, but the color import can be used with any sort of CSS-in-JS library such as Glamorous, Emotion, or Styled Components.

Sass

A similar approach would be used for projects that use Sass for their styles. All color variables should be kept in a variables.scss file with Sass variables beginning with $color- and ending with the name of the color as determined through Color Namer. Prefixing your variables with $color- allows code editors to list all colors when a user types $color- when declaring a color.

$color-blue-sparkle: #0076ff;
$color-black: #000000;
$color-pale-purple: #b089d5;
$color-berta-blue: #4bdaff;
$color-nero: #262626;
$color-mango: #ffa628;
$color-deep-lilac: #9b59b6;
$color-heartbeat: #aa0000;
$color-blood-burst: #ff4b4b;
$color-chicken-comb: #de2525;
$color-blood-organ: #630e10;
$color-school-bus-yellow: #ffd800;

The next step would be to have a second level of variable names to associate colors with more general groups.

$color-primary-background: $color-mango;
$color-secondary-background: $color-berta-blue;
$color-primary-text: $color-black;
$color-secondary-text: $color-nero;
$color-primary-button-background: $color-blood-organ;
$color-primary-button-text: $color-school-bus-yellow;

Here’s a demo of how this would look like in an application:

So that’s the approach I like to use when naming color variables in apps. In truth, I usually skip the second level of color variable names (e.g. $color-primary-background) and just straight up use the named colors (e.g. $color-school-bus-yellow). The reason being is that it eliminates the thinking involved when determining if a component should use $color-primary-background or if it should have a new color variable associated with it, such as $color-primary-nav-background.

If you found this article interesting and front end development interests you, consider following me on Twitter, Github, or LinkedIn.

✉️ Subscribe to CodeBurst’s once-weekly Email Blast, 🐦 Follow CodeBurst on Twitter, view 🗺️ The 2018 Web Developer Roadmap, and 🕸️ Learn Full Stack Web Development.

Untangling the Color Variable Mess in JavaScript and Sass Apps was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

T his article talks about a fictional scenario that tries to represent a near-ideal code review process. The story revolves around app development for a company and not an open source project. Also, it should be noted that this is an opinionated article of what makes a good code review. There are many different approaches that can make up an excellent code review process and the optimal process will vary depending on a variety of factors.

That being said, enjoy the story 📖

Meet Jimmy. Jimmy is working away on a new feature for his project. Jimmy and his team are using Git as their version control system and he is making his commits on a feature branch that will eventually get merged into the development (dev) branch (the team follows a GitFlow branching model). Before Jimmy can get his feature merged into the dev branch, his code needs to go through a code review.

Why does Jimmy’s code need to be reviewed before merging? Well, all the code in the dev branch should leave the project in a functional state and follow certain project level standards. Some examples of project level standards include adding the appropriate tests, correctly defining variable types, and having the code logic in the appropriate files/functions. Since Jimmy isn’t a perfect programmer (especially after a late night of binge watching the latest season of Black Mirror), his code needs to be checked by his team members.

Jim-bo works with 3 other team members. When Jimmy has completed his feature, he pushes his feature branch to Github and makes a Pull Request (PR) to initiate a code review. Jimmy then adds one or two of his teammates as reviewers to his pull request.

Why doesn’t Jimmy add all of his team members as reviewers? Well the more people that are asked to review the code, the more hours/resources you are dedicating to reviewing code and those hours can probably best be used on other things than having 3 people review the same code.

If the purpose for adding all team members to a PR is to receive the quickest response, this usually doesn’t work out as expected. There is usually one person that is the first to always review a PR and after this happens for many consecutive PRs, everyone expects the same person to review the pull request and then the requests for review end up getting ignored by most. This isn’t so bad for a team of 4, but the problem gets amplifies with larger teams.

If one of Jimmy’s teammates is a “senior” level developer and Jimmy is a “junior” level developer, this shouldn’t prevent Jimmy from being included in the code review process. Everyone should be able to participate in the code review process as it helps the team learn from each other. However, if Jimmy goes to review the PR and doesn’t understand much of what is going on in the code, he should not accept the PR because he “trusts” the work done by his team mate, but rather someone else should review the pull request.

Before Jim-mister adds his colleagues as reviewers to his PR, he needs to write a detailed Pull Request description that addresses the following:

• What has changed between his feature branch and the dev branch
• Checklist of prerequisites (e.g. added documentation, added tests, ready to merge, etc.)
• How to use the feature (a GIF of the feature in action is extremely useful here)
• How the design has changed and how it compares to the design mockups (screenshots comparing the designs to the implementation)
• Additional notes the reviewers should be made aware of

What goes into a pull request is usually highly project-dependant. Often times, you will see projects that have lots of pull requests make use of pull request templates to pre-populate a lot of the required information for the PR description.

Once Jimmy is done submitting his detailed pull request, he waits…but not too long!

A good review process requires that pull requests get addressed as soon as possible in order to prevent the project from being impeded. Ideally, pull requests are reviewed within two hours of their submission.

Think of this for a minute, if a PR is submitted by Jimmy, he will likely tackle some smaller tasks on his plate, such as responding to email or maybe addressing some tasks on the internal projects he is working on. If an hour goes by and nobody has reviewed his PR, Jimmy will have to start working on a new feature for the project. Let’s say that he is 3 hours into working on a new feature and then he finally receives feedback on his PR which requests some changes. Jimmy then switches back to his old feature branch to address the issues on his code review and then leaves a message on the PR saying that his PR is ready to be re-reviewed. Jimmy switches back to the new feature he has started and doesn’t get additional feedback on the PR until mid-day the following day where he is asked for EVEN MORE modifications. As you can see, this process is being drawn out and requires a lot of context switching, which usually hinders productivity.

So ideally, Jimmy’s PR quickly gets reviewed by his colleagues and he receives requests for changes on certain parts of his feature. The feedback Jimmy receives is worded so as to explain what should be changed and more importantly, WHY it should be changed (some comments even include links to external documentation/articles that provide more detailed information on the subject). This is extremely helpful for Jimmy because he can learn from his mistakes and better understand the best practices that should be followed. The language Jimmy’s teammates use in their feedback is friendly and isn’t in any way accusatory or trying to shame Jimmy.

Ok, now that Jimmy-two-shoes has received his feedback, he can now act on it by applying changes to his code. Ideally, Jimmy uses interactive rebasing when making changes so as not to add extra commits to his branch with commit messages such as “Fixed xxx” or “Added more tests”. Interactive rebasing allows previous commits to be edited with additional changes. Here’s an illustration of what Jimmy’s commits should look like after updating his feature branch with the feedback he received on his pull request:

Notice how, for the recommended way of doing things, the commits are the same before and after the changes have been made to the feature branch? This is because an interactive rebase was used to edit individual commits. So instead of making a commit such as “Added more Jest tests”, the commit called “Added Jest tests” would be modified to include the added tests. This way, all the commit messages are still relevant and then there are not a bunch of extra commits spread about the feature branch.

Ok, so Jimmy made his changes, he pushed his changes to Github and has notified the other reviewers of his changes. If there are additional changes requested by Jimmy’s teammates, he will address those, otherwise Jimmy can merge his changes into the development branch. Jimmy proceeds to high-five all his teammates, bust out some office break-dance moves, and can continue living a full life.

That’s what I would describe as an ideal code review process. Does this always end up being followed? Unfortunately, no. Sometimes reviewers are too busy and don’t make the time to promptly review PRs. Other times the details of a PR are not clearly outlined in the Pull Request message and this makes it more difficult for the reviewers to provide a beneficial review. That being said, it is something to strive for and will make the development process more enjoyable.

Be like Jimmy and his perfect teammates and make the development world a better place for everyone 👫👬👭.

Other resources related to code reviews and pull requests

Giving and Receiving Great Code Reviews

10 Principles of a Good Code Review

Top ten pull request review mistakes

The Art of Humanizing Pull Requests

The Perfect Code Review Process was originally published in Osedea on Medium, where people are continuing the conversation by highlighting and responding to this story.

I listened to a great Syntax FM podcast that summarized useful JavaScript array and object methods. These methods help developers write clean and readable code. A lot of these methods reduce the need to reach for utility libraries like Lodash.

All the methods in this article are chainable, meaning they can be used in combination with one another and they also don’t mutate data, which is especially important when working with React. With all these array and object methods you’ll find you never have to reach for a for or while loop ever again.

.filter()

Creates a new array based on whether the items of an array pass a certain condition.

Example

Create an array of student ages that meet the legal drinking age.

const studentsAge = [17, 16, 18, 19, 21, 17];
const ableToDrink = studentsAge.filter( age => age > 18 );

// ableToDrink will be equal to [19, 21]

.map()

Creates a new array by manipulating the values in another array. Great for data manipulation and it is often used in React because it is an immutable method.

Example

Create an array that adds a $ to the beginning of each number.

const numbers = [2, 3, 4, 5];
const dollars = numbers.map( number => '$' + number);

// dollars will be equal to ['$2', '$3', '$4', '$5']

.reduce()

This often overlooked method uses an accumulator to reduce all items in an array to a single value. Great for calculating totals. The returned value can be of any type (i.e. object, array, string, integer).

Example

Add up the integers in an array.

const numbers = [5, 10, 15];
const total = numbers.reduce( (accumulator, currentValue) => accumulator + currentValue);

// total will be equal to 30

There are some really cool use cases for .reduce() outlined in the MDN docs that provide examples on how to do things likes flattening an array of arrays, grouping objects by a property, and removing duplicate items in array.

.forEach()

Applies a function on each item in an array.

Example

Log each array item to the console

const emotions = ['happy', 'sad', 'angry'];
emotions.forEach( emotion => console.log(emotion) );

// Will log the following:
// 'happy'
// 'sad'
// 'angry'

.some()

Checks if any item in an array passes the condition. A good use case would be checking for user privileges. It can also be used similarly to a .forEach() where you would perform an action on each array item and break out of the loop once a truthy value is returned.

Example

Check if there is at least one 'admin' in an array.

const userPrivileges = ['user', 'user', 'user', 'admin'];
const containsAdmin = userPrivileges.some( element => element === 'admin');

// containsAdmin will be equal to true

.every()

Similar to .some(), but checks if all items in an array pass a condition.

Example

Check if all ratings are equal to or greater than 3 stars.

const ratings = [3, 5, 4, 3, 5];
const goodOverallRating = ratings.every( rating => rating >= 3 );

// goodOverallRating will be equal to true

.includes()

Checks if an array contains a certain value. It’s similar to .some(),but instead of looking for a condition to pass, it looks if the array contains a specific value.

Example

Check if the array includes an item with the string ‘waldo’.

const names = ['sophie', 'george', 'waldo', 'stephen', 'henry'];
const includesWaldo = names.includes('waldo');

// includesWaldo will be equal to true

Array.from()

This is a static method that creates an array based on another array or string. You can also pass a map callback function as an argument to further shape the data in the new array. Honestly, I’m not too sure why someone would use this over the .map() method.

Example

Create an array from a string.

const newArray = Array.from('hello');

// newArray will be equal to ['h', 'e', 'l', 'l', 'o']

Create an array that has double the value for each item in another array.

const doubledValues = Array.from([2, 4, 6], number => number * 2);

// doubleValues will be equal to [4, 8, 12]

Object.values()

Return an array of the values of an object.

Example

const icecreamColors = {
    chocolate: 'brown',
    vanilla: 'white',
    strawberry: 'red',
}

const colors = Object.values(icecreamColors);

// colors will be equal to ["brown", "white", "red"]

Object.keys()

Return an array of the keys of an object.

Example

const icecreamColors = {
  chocolate: 'brown',
  vanilla: 'white',
  strawberry: 'red',
}

const types = Object.keys(icecreamColors);

// types will be equal to ["chocolate", "vanilla", "strawberry"]

Object.entries()

Creates an array which contains arrays of key/value pairs of an object.

Example

const weather = {
  rain: 0,
  temperature: 24,
  humidity: 33,
}

const entries = Object.entries(weather);

// entries will be equal to
// [['rain', 0], ['temperature', 24], ['humidity', 33]]

Array spread

Spreading arrays using the spread operator (…) allows you to expand the elements in an array. It’s useful when concatenating a bunch of arrays together. It’s also a good way to avoid using the splice() method when looking to remove certain elements from an array because it can be combined with the slice() method to prevent direct mutation of an array.

Example

Combine two arrays.

const spreadableOne = [1, 2, 3, 4];
const spreadableTwo = [5, 6, 7, 8];

const combined = [...spreadableOne, ...spreadableTwo];

// combined will be equal to [1, 2, 3, 4, 5, 6, 7, 8]

Remove an array element without mutating the original array.

const animals = ['squirrel', 'bear', 'deer', 'salmon', 'rat'];
const mammals = [...animals.slice(0,3), ...animals.slice(4)];

// mammals will be equal to ['squirrel', 'bear', 'deer', 'rat']

Object spread

Spreading an object allows for the addition of new properties and values to an object without mutations (i.e. a new object is created) and it can also be used to combine multiple objects together. It should be noted that spreading objects does not do nested copying.

Example

Add a new object property and value without mutating the original object.

const spreadableObject = {
  name: 'Robert',
  phone: 'iPhone'
};

const newObject = {
  ...spreadableObject,
  carModel: 'Volkswagen'
}

// newObject will be equal to
// { carModel: 'Volkswagen', name: 'Robert', phone: 'iPhone' }

Function Rest

Functions can use the rest parameter syntax to accept any number of arguments as an array.

Example

Display the array of passed arguments.

function displayArgumentsArray(...theArguments) {
  console.log(theArguments);
}

displayArgumentsArray('hi', 'there', 'bud');

// Will print ['hi', 'there', 'bud']

Object.freeze()

Prevents you from modifying existing object properties or adding new properties and values to an object. It’s often what people think const does, however const allows you to modify an object.

Example

Freeze an object to prevent the name property from being changed.

const frozenObject = {
  name: 'Robert'
}

Object.freeze(frozenObject);

frozenObject.name = 'Henry';

// frozenObject will be equal to { name: 'Robert' }

Object.seal()

Stops any new properties from being added to an object, but still allows for existing properties to be changed.

Example

Seal an object to prevent the wearsWatch property from being added.

const sealedObject = {
  name: 'Robert'
}

Object.seal(sealedObject);

sealedObject.name = 'Bob';
sealedObject.wearsWatch = true;

// sealedObject will be equal to { name: 'Bob' }

Object.assign()

Allows for objects to be combined together. This method is not really needed because you can use the object spread syntax instead. Like the object spread operator, Object.assign() does not do deep cloning. Lodash is your best friend when it comes to deep cloning objects.

Example

Combine two objects into one.

const firstObject = {
  firstName: 'Robert'
}

const secondObject = {
  lastName: 'Cooper'
}

const combinedObject = Object.assign(firstObject, secondObject);
// combinedObject will be equal to { firstName: 'Robert', lastName: 'Cooper' }

If you found this article interesting and front end development interests you, consider following me on Twitter, Github, or LinkedIn.

✉️ Subscribe to CodeBurst’s once-weekly Email Blast, 🐦 Follow CodeBurst on Twitter, view 🗺️ The 2018 Web Developer Roadmap, and 🕸️ Learn Full Stack Web Development.

Useful Javascript Array and Object Methods was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Rebase — One of the Most Powerful Git Commands

W hen a programmer is first learning git the typical commands that are picked up include add, commit, push, pull, status, branch, checkout and merge. After those foundational commands are learned, I think that the rebase command should be understood.

Rebasing is often used as an alternative to merging. Rebasing a branch updates one branch with another by applying the commits of one branch on top of the commits of another branch. For example, if working on a feature branch that is out of date with a dev branch, rebasing the feature branch onto dev will allow all the new commits from dev to be included in feature. Here’s what this looks like visually:

For the above example, this is what it would look like from the command line:

git rebase feature dev

However, it is more common to first checkout a branch and then run the rebase command with the name of the branch you wish to rebase on to:

git checkout feature
git rebase dev

Typical Rebase Use Cases

Updating a Feature Branch

Lets say you’re working away on a feature branch, minding your own business.

Then you notice some new commits on dev that you’d like to have in your feature branch, since the new commits may affect how you implement the feature.

You decide to run git rebase dev from your feature branch to get up-to-date with dev.

However when you run the rebase command, there are some conflicts between the changes you made on feature and the new commits on dev. Thankfully, the rebase process goes through each commit one at a time and so as soon as it notices a conflict on a commit, git will provide a message in the terminal outlining what files need to be resolved. Once you’ve resolved the conflict, you git add your changes to the commit and run git rebase --continue to continue the rebase process. If there are no more conflicts, you will have successfully rebased your feature branch onto dev.

Now you can continue working on your feature with the latest commits from dev included in feature and all is well again in the world. This process can repeat itself if the dev branch is updated with additional commits.

Updating a Feature Branch Prior to Merge

Another popular use for rebasing is to rebase a feature branch, just prior to merging into a dev branch. Let’s say that the current state of a feature and dev branch is as follows:

Once thefeature is complete, it should be merged into the dev branch. First, thefeature branch should be updated with dev using git rebase dev.

Next, merge feature into dev. This is usually done through a Pull Request, so others can review the work done in the feature branch. Once this is done, the result is as follows:

Notice how all the commits from the feature branch are added to the end of the dev branch. This will always be the case if rebasing is immediately done prior to merging. The reason this happens is that rebasing rewrites the git history and so the timestamp of the commits on the rebased branch will all be the moment at which the rebase command was run. To be clear, rewriting history with rebase recreates commits that contain the same changes and commit message, but with a new hash and timestamp. Therefore, when merging a recently rebased feature branch into dev, all the feature branch commits will be added at the end of dev since merging orders commits in chronological order.

Github actually has an option on Pull Requests to rebase a branch prior to merging.

Renaming & Consolidating Commits in Feature Branches

Odds are, when nearing the completion of a feature in a feature branch, the commit history could be improved upon by renaming some commits to something more appropriate, combining closely related commits, and/or reordering commits in a more logical order. Rebasing allows for all of this!

Since rebasing rewrites the git history, it provides some tools to specify exactly how to rewrite the history. The best way to take advantage of these extra rebase features is by running rebase in interactive mode by passing the -i flag with the command (i.e. git rebase -i feature dev).

When running an interactive rebase, a list of commits that will be rebased along with the word pick at the beginning of each commit message is presented in the default git editor configured on your machine (in my case it’s Visual Studio Code). The word pick can be changed with any of the following options (all of which are listed when running an interactive rebase):

pick = use commit
reword = use commit, but edit the commit message
edit = use commit, but stop for amending
squash = use commit, but meld into previous commit
fixup = like "squash", but discard this commit's log message
exec = run command (the rest of the line) using shell
drop = remove commit

For the examples mentioned earlier here’s how you would tackle them:

• A commit message can be reworded using the reword option for a commit.
• Combining commits is done with the squash or fixup option on a commit that should be combined with another commit. Ensure that the commit specified with squash/fixup immediately follows the commit with which it should be combined.
• Reordering commits is as simple as moving around the commit messages in the desired order.

What’s So Great About Rebasing?

No Merge Commits

Merging two branches together always requires a merge commit. If a feature branch is continually being updated with a dev branch using a merge, there will be several merge commits resulting in a less clear git history.

These merge commits can be completely mitigated if rebase is used to update the feature branch instead of a merge.

Linear & Sequential Git History

When rebasing a branch prior to a merge, all the the feature branch commits are grouped together at the end of the dev branch whereas the feature branch commits are interspersed in the dev branch when a rebase is not used prior to merge. This is because merging orders commits chronologically. Grouping feature commits together, as is the case with a rebase, makes it simple to understand/analyze the git history afterwards.

Simpler Time Resolving Conflicts

When rebasing, git applies each commit one at a time and so conflicts can be resolved progressively. When resolving conflicts for a merge, all conflicts must be resolved at once which can make it a bit more difficult to handle.

If a conflict is encountered while rebasing, git will indicate which files are conflicting and need to be modified. After changes have been made, the changes need to be staged to the commit and then the rebase can resume using git rebase --continue. There is also the option of running git rebase --abort while resolving conflicts in a rebase, which will cancel the rebase and leave the branch unchanged.

Well Organized and Clean Git History

With all the benefits above in addition to the ability to change commit messages, combine commits, and reorder commits, rebasing makes for a very clean git history that is easy to understand. Having an understandable git history is great when trying to pinpoint when a certain feature or bug was introduced in your codebase.

When Not To Rebase

Ok, rebasing is pretty sweet, but there are certainly cases where you should not rebase. The golden rule of rebasing is to not rebase public branches. The reason you shouldn’t rebase a public branch is that you are rewriting the git history for that branch and this will result in your version of the public branch to differ from the version other users are working with. This will result in a bunch of conflicts and can be a tedious problem to resolve once it’s done, so make sure to only rebase branches you, and only you, are working on.

Adding git rebase to your git workflow can be an extremely valuable way of cleaning up your git history and making the overall git workflow easier to work with. The way rebase works may not be completely intuitive at first, but after using the command a few times on feature branches to better familiarize yourself with it, you’ll hopefully end up seeing some of the benefits mentioned in this article.

Related Git Rebase Resources & Readings

Git Rebase Documentation

Merging vs. Rebasing — Bitbucket

Git Time Travel Magic — Gant Laborde

Rebase — One of the Most Powerful Git Commands was originally published in Osedea on Medium, where people are continuing the conversation by highlighting and responding to this story.