Forem: Gabriel

Installing Java on MacOS using Homebrew and JEnv

Gabriel — Thu, 27 Aug 2020 19:34:43 +0000

I think its fair to say that going through the process of installing Java on any machine is in of itself a bit confusing. For those that come from NodeJS, installing a new version of Node is as easy as installing nvm and running nvm install [some nodejs version] and calling it a day.

The goal of this post is to show that we could do just that with Java, install a package to allow us to toggle between Java versions and set our JAVA_HOME path automatically for us just by running a few simple commands.

Before we start, ensure that you have homebrew installed and that you have updated all dependencies (ie. run brew upgrade)

First, we need to install JEnv using homebrew, run the following command:
```
$ brew install jenv 
```
Next, ensure that jenv is listed as a command on your shell, if you are using bash, then run
```
$ echo 'export PATH="$HOME/.jenv/bin:$PATH"' >> ~/.bash_profile
$ echo 'eval "$(jenv init -)"' >> ~/.bash_profile
```
If using .zshrc, then run the following
```
$ echo 'export PATH="$HOME/.jenv/bin:$PATH"' >> ~/.zshrc
$ echo 'eval "$(jenv init -)"' >> ~/.zshrc
```
Note: It's important that now you restart your bash terminal or run . ~/.zshrc to reload your .zshrc now that we have added a new command shortcut.
Now let's go ahead and download a brew cask for the jdk version that we are after. Before we go and download the version that we need, ensure that you run the following command to add the brew repo to your machine (https://github.com/AdoptOpenJDK/homebrew-openjdk). Note that to install oracle-jdk , check out the instructions listed here https://formulae.brew.sh/cask/oracle-jdk. Note that the following steps will be only to install the AdoptOpenJDK and not the Oracle JDK. If you need some info on the differences between each type, check out https://www.openlogic.com/blog/java-experts-openjdk-vs-oracle-jdk#:~:text=The biggest difference in OpenJDK,JDK requires a commercial license.&text=Since January 2019%2C businesses now,order to receive software updates.
```
$ brew tap AdoptOpenJDK/openjdk
```
Now that we have the AdoptOpenJDK, let's run the following command to install Java 8 (jdk 1.8.x )
```
 $ brew cask install adoptopenjdk8
```
Once the installation completes, we'll then follow up with jenv to add this version into our list of available version to be able to toggle between versions. Let's ensure that we know the location where the jdk package was installed, for MacOS Catalina, that should be under the following directory /Library/Java/JavaVirtualMachines
If we cd into /Library/Java/JavaVirtualMachines we should see the following:
```
adoptopenjdk-8.jdk
```
If the above is correct, we'll go ahead and run the following command to add the location of this version to jenv
```
$ jenv add /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home
```
To confirm that the version is now available on jenv, run the following command jenv versions, you should see the following output:
```
openjdk64-1.8.0.252
```
Now to add Java 8 as your overall global java version, run the following command:
```
jenv global openjdk64-1.8.0.252
```
Now, run java -version and you should see the following output:
```
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.252-b09, mixed mode)
```
Note: If you still see your old version or nothing at all, ensure that you restart your bash terminal (or .zsrh) to pull in the new path to your Java home (this is set by jenv itself, you don't need to do anything).

That's it! Hopefully it was painless and straightforward, next time you need to toggle between versions, just run jenv {version} and you're all set.

You could also set versions of Java specific to your shell terminal, or directory, simply replace global with local (if you are within a specific directory) or shell for adding a version to specific to the shell you're running.

Resources:

Composable Context API with Hooks

Gabriel — Wed, 03 Jul 2019 13:56:09 +0000

React's ContextAPI is a great light-weight alternative to using Redux for global state management.

Its important to understand that not every component will require the use of React's ContextAPI, or any global state management tool in general for the most part. Ideally, components should exist in a "functional" state-less fashion for as long as possible. For instance, not carrying any state, and instead, leveraging real-time values passed in through props.

For example:

    const UserNameDisplay = (props) => (<span>props.userName<span/>);

This state-less design enables for easier testing, and forces the logic and state to be kept in the component's parent. Essentially, keeping state centralized to prevent off-sync state within the app.

However, in our case, we do want to have an encompassing component that we could leverage to provide us with a state, and a way to alter that state across any component that requires it.

If we take a TODO app for example, more than likely we know we may need to keep a reference to the TODO items on the application at any one given time. This enables the children from the main top-level component, say for example, the Todo component, from having to drill down the state of the todos down to each child component, and then each child that would require the todos would then in part need to drill down todos further down the chain.

For example (Not the right way of doing things):

    const SomeOtherChildComponent = ({todos}) => {
            return (
                <AnotherChildComponent todos={todos}/> // you get the idea by now ...
            )
    }

    const TodosMainComponent = () => {
        const todos = [];
        return (
            <SomeOtherChildComponent todos={todos}/>
        )


    }

This is quite cumbersome. Prop drilling is perfectly fine if we are dealing with one level of component depth, however, when we have multiple levels of depths required, ContextAPI would provide for a better way of "Handing down" state to the child components of TodosMainComponent.

The idea is that we have a Provider component that sets up our state, and as many Consumer components to, well, consume that state.

Here's the gist:

    <SomeContext.Provider value={someState}>

        <SomeComponent/>

    </SomeContext.Provider>

Ideally, we'd like a way to define our Context in a more "composable" way.

We can leverage the concept of React's Hooks to create a custom component that introduces a specific context state. In this case, a todo state. Stackblitz Todo Context Example

Setting up Reducer and Initial State:

Let's start by first defining our reducer structure:

    import { HYDRATE_TODOS } from "./actionTypes";

    export const initialState = {
      todos: []
    };

    const reducer = (state = initalState, { type, payload }) => {
      switch (type) {
        case HYDRATE_TODOS:
          return { ...state, todos: payload };
        default:
          return state;
      }
    };

    export default reducer;

Wiring up our Composed Provider Component:

We could have just defined the todos using the useState hook, since we are just dealing with an array of objects (single value), however, for the purposes of scaling this to also add in additional properties/actions to the state (Add, Remove, Update etc), we'll just start with a reducer.

    import React, { createContext, useReducer } from "react";
    import reducer, { initialState } from "./reducer"; // our reducer from above

The first thing we'd have to do is ensure that we are creating a React context

    import React, { createContext, useReducer } from "react";
    import reducer, { initialState } from "./reducer"; // our reducer from above

    export const TodosContext = createContext(); // our context for todos

Now, we can create a component that would accept other components as a "props" passed in. We can think of this component as the "Parent" component that will initialize our context and pass the context down to the children (the components passed in).

    import React, { createContext, useReducer } from "react";
    import reducer, { initialState } from "./reducer"; // our reducer from above

    export const TodosContext = createContext(); // our context for todos

    export const TodosProvider = ({ children }) => {
      const [state, dispatch] = useReducer(reducer, initialState); // intialize our reducer
      const value = [state, dispatch]; // what we'll expose to all children components

      return (
        <TodosContext.Provider value={value}>{children}</TodosContext.Provider>
      );
    };

Oh hey, look at that, we've essentially created a reusable component we can bring in to initialize our todo's context and pass in as many children as we'd like. This works in a similar fashion to that of React's Router. Where you have the main router component and the child routes nested underneath:

    <Router>
        <Route/>
        <Route/>
    </Router>

Its important to understand that we are essentially exposing the state and dispatch properties to all our child components. This would essentially allow our child components to alter the todo state by dispatching actions to our todos reducer, and also to read in our todos by using the state prop.

That's essentially all we need in terms of context scaffolding setup. Let's use it!

Using the TODO Provider Component:

In our example case from above, we'll refactor the TodosMainComponent and its ChildComponent to display the list of TODOs using our new TodoContext:

    import React, { useContext, useEffect, Fragment } from 'react';
    import { TodoProvider, TodoContext } from './todos/contexts/TodoContext' // import our context provider
    import { HYDRATE_TODOS } from "./actionTypes";

    const TodoApp = () => {
        return(
            <Fragment>
                <TodoProvider> //remember, we've already setup this provider with the value and initial state
                    <TodosMainComponent/>
                </TodoProvider>
            </Fragment>
        )
    }

    const SomeOtherChildComponent = () => {
            const [{todos}, todoDispatch] = useContext(TodoContext); // we can dispatch events or leverage the todo state here

            const displayItems = (todos) => todos.map(todo =>
          <li key={todo.id.toString()}>{todo.body}</li>
      );

          return (
            <ul>{displayItems(todos)}</ul>
          )
    }

    const TodosMainComponent = () => {
        const someTodoList = [{id: 1, body: 'Some todo'}];
        const [{ todos }, todosDispatch] = useContext(TodoContext);

        useEffect(()=> {
            todoDispatch({type: HYDRATE_TODOS, payload: someTodoList});
        }, []);

        return (
            <SomeOtherChildComponent/>
        )
    }

Conclusion

Obviously, this is a very simple example of the concepts, however, in real practice, it may be more suitable to wrap a set of routes in a particular context. For instance, you could do something like this:

    <TodoProvider>
            <Route path="/" exact component={TodoMainComponent} />
            <Route path="/todos/add" exact component={Add} />
    </TodoProvider>

This would allow you to insert todo's into your state from your Add component, and avoid having to go back to your backend to refresh the local state data.

We also need to keep in mind that React will eagerly re-render your components given any state change. So if you have a really large sub-tree of child components nested under one context, it may be worth looking into splitting your state and thus having multiple context's with a smaller child component set.

Kent C Dodds also proposes an alternative solution to solving the performance issues introduced by complex, fast changing context values. The idea here is that we'd split our actual state into its own provider, and our reducer dispatch function into another provider. Enabling only the components that are reading the todo state to render, but not any component that only alters the state. This may be a great solution if you have functional components such as buttons, menu displays, navigation footers etc.

If you are more interested in other solutions to improving React's Context API performance on large subtrees, check Dan Abramov's proposed solutions on this.

Resources

Inspiration for this post was drawn from Eduardo Robelos's post on React Hooks: How to create and update Context.Provider

Debugging Webpack for Beginner Contributors

Gabriel — Sun, 18 Nov 2018 03:58:57 +0000

I recently started to think about how I could contribute more to open source. I think that is a thought that we all as developers have come across once or twice in our careers. I mean, we use so much open source code, the idea of contributing back to the community seems like an easy task in itself right?

I took a look around to see what type of projects I would like to contribute to, and I decided to look first at the projects that I used the most in my day to day work or as part of my side projects.

Webpack seems to that project for me :)

Intimidating Codebase

Thinking of Webpack as my first open source project to contribute towards felt extremely intimidating. Webpack in itself is massive, and has a rather healthy and strongly opinionated community around it (Nothing wrong with that of course). However, as an aspiring open source contributor, it certainly looked to me as a massive challenge to just understand how it worked under the hood so to speak.

Debugging

This takes me to my first challenge, how the heck do I debug this massive codebase? After all, most of us consider debugging a codebase as the first step towards understanding the control flow and logic.

Assumptions

I'm assuming that you already have a version of Webpack forked and cloned to your local machine. In my case, I forked the latest Webpack 3 (or latest) branch.

git checkout remotes/origin/webpack-3

Then, you'll more than likely want to run either npm i or yarn to pull all the node_modules goodies.

VSCode Setup

I'm assuming that you also are working in VSCode, so we'll want to setup our debug configuration.

Here's the minimum config you'll need to get started:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "attach",
      "name": "Attack-Webpack-Debug",
      "port": 9229,
      "skipFiles": ["${workspaceFolder}/node_modules/**/*.js"]
    }
  ]
}

Here we are just saying that we want to attach to the running debugging process on port 9229, and that we want to avoid debugging or stepping through the files under node_modules.

Another important/convient step, is to enable Auto Attach. You can toggle this setting on the bottom settings bar of VSCode:

This will allow you to toggle the debugger screen automatically once we execute our node --inspect-brk command.

Setup Project to Debug Against

Alright, so we'll need a sample project to have Webpack bundle up for us. It's quite simple, go ahead and setup another folder outside of the forked Webpack project folder.

mkdir sample-webpack
touch client.js
vim client.js -> add a few lines of code, like console.log('Test') etc.

That's about it! Now go back to your Webpack repo, and then we can finally run our debug commands!

Node Inspect

Once on your Webpack repo, we'll run a quick command to bundle the client.js file.

Run the following command:

node --inspect-brk bin/webpack.js --entry ./client.js --output-filename bundle.js

This will trigger the debugger window and will break on the first line. You can then set a breakpoint on VSCode and step through the Webpack source!

That's it! ✅

Go ahead and play around! If you want to do more elaborate Webpack config debug, just pass a webpack.config.js from your sample project like this:

node --inspect-brk bin/webpack.js --config ./webpack.config.js

Feel free to leave a comment below if you have any questions or any of these steps don't work for your setup 💯