The issue

As a Windows user, you may face some issues trying to run NPM scripts that contain shell syntax.

Even if you try to use PowerShell, you may face syntax errors.

Ok, we know the CMD is legacy and it’s not able to run any code written in shell-script, but how about Powershell?

The “but”

Isn’t Powershell able to run shell-script properly? The answer is YES. But, there are some tricky details about how NPM runs its scripts.

Internally NPM runs your scripts on the default command terminal, independently from where you are triggering the scripts.

This fact could confuse you a lot. You may think once you are running the script from PowerShell you will be able to run shell-script syntax. 💥

On Windows, it means it runs every script on CMD, and as I said before it’s not compatible with shell-script syntax.

The solution

The solution for it is pretty simple, you just need to set a shell-script syntax compatible terminal as the default NPM script runner.

I know I am talking about Powershell since the beginning, but I will personally recommend you to use GitBash, so check below how to set it as your default NPM script runner.

Open your cmd and run:

npm config set script-shell "C:\\Program Files (x86)\\git\\bin\\bash.exe"

For x64 installations

npm config set script-shell "C:\\Program Files\\git\\bin\\bash.exe"

With this solution, I am considering you have GitBash installed at these locations. Always check before if it’s the location your GitBash is installed. Otherwise, you must change the path used on these examples by your current GitBash directory path.

Need to revert?

If you need to revert the configuration presented before, don’t worry. Run the following command to accomplish it.

npm config delete script-shell

That’s all folks.

I don’t know you but I like to see my terminal with colors and icons that help me to see where and what I am doing.

I use to refer ZSH to my friends who just arrive at the Mac OS X dev environment. Also, I use to hear from them that they didn’t get something next to my own terminal configuration.

That’s why I decide to write this simple article to help you guide through the steps to get an Oh My ZSH! terminal with Monokai theme and Powerline fonts.

Let’s get to the point!

Install Oh My ZSH! via curl

$ sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

Install Powerline fonts

Clone powerline fonts repo:

git clone https://github.com/powerline/fonts.git --depth=1

Install them:

cd fonts
./install.sh

Don’t mess up your folders! Recycle the stuff you don’t need anymore:

cd ..
rm -rf fonts

Finally, set a theme up.

lysyi3m/macos-terminal-themes

I personally use the “Monokai Pro (Filter Spectrum)” one.

Once downloaded a theme, open it with terminal, and it gets installed to your local themes automatically.

• To set the theme, open terminal preferences, choose the theme you installed, and check it as default.
• To set the fonts, still, at terminal preferences, click on the Change… button in the Font section.
• I suggest the Meslo LG M DZ for Powerline, Regular, 11px! It fits very well on the terminal.
• Doing the steps above, you will be able to see the colors and icons when for example, inside a git folder.

Bonus

Cleaning up the terminal context.

Use your preferred editor to edit the .zshrc file:

code .zshrc

Set the ZSH theme to the agnoster:

ZSH_THEME=”agnoster”

Then, append the following instruction to hide the terminal context:

prompt_context(){}

If you want to personalize it, see that discussion.

Setting Visual Studio Code up as well

Open the VS Code configs and drop the following lines:

"terminal.integrated.fontFamily": "Source Code Pro for Powerline",
"terminal.integrated.shell.osx": "/bin/zsh"

That’s all!

I hope now you have a cool terminal to work with!

Hi there,

At this story, we will see how to create an ASP.NET Core service, build a Docker image with that service, how to process it through AWS Code Pipelines, and automatically deploys it to an Elastic Beanstalk instance.

First steps

The ASP.NET Core web project

Run the scripts to above to get a brand new web project.

mkdir aspnetcore-api-aws
cd aspnetcore-api-aws
dotnet new web

Then, feel free to change your endpoints on the Startup.cs file as you want.

The Buildspec file

Create a Buildspec.yml file as below.

version: 0.2

phases:

pre_build:

commands:

- dotnet restore

build:

commands:

- dotnet publish -o output

- mkdir build

- cp -R output build/output

- cp Dockerfile build/Dockerfile

artifacts:

files:

- '**/*'

base-directory: build

What that file defines is:

• Restore the project dependencies into a pre-build phase.
• Publish the project to an output folder
• Create a folder named build
• Copy the output and Dockerfile to inside the build folder.
• Then, it defines all files inside the base directory build to be copied as artifacts.

The Dockerfile

Create a Dockerfile as below.

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1

COPY output/* /app/

EXPOSE 80

ENTRYPOINT ASPNETCORE_URLS=http://*:80 dotnet /app/aspnetcore-api-aws.dll

It starts an image from aspnet:3.1 templates, copy the content on the output folder to inside the container, define the port at 80, and define an startup execution point that runs our aspnetcore application at port 80.

At GitHub

Of course, create a GitHub repository, commit, and push all your code to the master branch.

No more code from that point! :D

The AWS services

The Elastic Beanstalk service

Create a elastic beanstalk application and then a new application environment as a Web server environment.

On platform options, choose Docker as below:

Afterward, it’s gonna be star… Wait for it! …ted.

You must see a website as the following image when accessing your environment URL.

The CodePipeline service

Create a CodePipeline and give a name to it. Select GitHub as a source provider and connect to it. Choose your GitHub project and the master branch.

At the Build Stage section, select AWS CodeBuild as the provider, and at the same flow, create a new CodeBuild project on the popup, with the environment settings as following.

Leave the Buildspec config as it is. Remember! The CodeBuild will use our repository’s Buildspec file.

At the Deploy section, select AWS Elastic Beanstalk as the provider. Also, select the application and environment we previously created.

Review everything and click on Create Pipeline.

Now, let the Pipeline get everything setup.

If everything went well, you will see the Pipeline steps as the image below.

It means your Pipeline worked properly. Just check the environment URL out, to see your service online.

Conclusion

All these tools together provide a good solution for our continuous integration and delivery.

You may need functionalities like blue/green deployment, for example. So, that’s why it worth checking out more functionalities through Elastic Beanstalk instances and Code Pipelines documentations.

If you want to check my GitHub repository used on that example, check it out on the following link.

fmacedoo/aspnetcore-api-aws

Thanks you all!

Sometimes we need to build some kind of application that does not need to consume any online service and we need to store data at the same time. Local storage could be an option in some cases, but a few weeks ago I’ve faced a project requirement where the application must store massive data collected in field research at remote places with no internet connection.

The collectors were using a kind of windows application built with the C# Windows Forms framework and SQLite that I created. With that stack, it’s simple to open a file or even connect to a database, as the process who runs the application is the same main process that launched it.

Of course, the collectors came back to me asking about new requirements on the application, and as I’ve learned and improved much more my skills I decided to rewrite the small application using that new stack proposed at the story title.

TL;DR;

Let’s get to what lights up our eyes

First of all, we must use create-react-app to bootstrap our application and then install some dependencies related to the Electron.

create-react-app app

yarn add electron electron-builder wait-on concurrently --dev

yarn add electron-is-dev

Add this electron.js file to the “public” folder.

Add the “main” property to package.json and point to our electron file:

“main”: “public/electron.js”

Add this script to run the dev version:

"electron-dev": "concurrently \"BROWSER=none yarn start\" \"wait-on http://localhost:3000 && electron .\""

Run the script:

yarn electron-dev

Now you have a sample electron app running. It’s basically what a guy named Kitze wrote here.

What now? How to connect to an SQLite data source?

At this point, We’re about to use something named Electron ipcMain and ipcRenderer. They are both a Node.js Event Emitter. Essentially we use them to communicate between the main process to the render process and vice-versa.

Having these tools on our hands, let’s “ping pong” it.

Write a function to allow the renderer to say ping to the main process. It will send a message named asynchronous-message to the main process and will be waiting once for a response named asynchronous-reply.

As our renderer.js will be imported by the Electron renderer process, we must explicit we want Node integration at our created BrowserWindow. So, get back to electron.js and put this there.

new BrowserWindow({
    ...
    webPreferences: {
      nodeIntegration: true,
    }
});

That’s how the electron dependencies are injected into the browser window. Afterward, we import the dependency from the window variable as you could see on the renderer.js file.

const electron = window.require('electron');

Now, write a function to allow the main process to receive the renderer message (asynchronous-message) and respond it back (asynchronous-reply).

Import the main.js on our electron.js file. Remember that file, right?

// preferable require it right after the main imports.
require('../src/message-control/main');

On our web application (the renderer), create basic logic just to see that behavior happening.

Awesome, we already have our web application communicating to the main process, which is so powerful in terms of access.

You may say: “Ok, we’ve already played a lot with it but you didn’t show me anything about SQLite yet.”

Yeah, I did this on purpose to make sure you understood the concept of the communication between both processes (main and renderer).

So, talking about SQLite… add it.

yarn add sqlite3

Tip: Add an SQLite database file to the public folder. I suggest you use the DB Browser for SQLite tool.

Change the main.js to receive a SQL statement, run it, and send the result back to the renderer via event.

Change the App.js to treat the result as an array, as below:

Now, you must see the query results on the app screen. Simple as it is.

Ok! That’s all folks.

Did you get a kind of ‘module not found’ error about SQLite?

That’s because sqlite3 isn’t a native module, as in Node.js only 400 modules are native, against the 650,000 modules available.

https://www.electronjs.org/docs/tutorial/using-native-node-modules

But, if you wanna solve that, repeat the following steps:

yarn add --dev electron-rebuild

Add to your package.json:

“rebuild-sqlite3”: “electron-rebuild -f -w sqlite3”

Run:

yarn rebuild-sqlite3

It could be a bit tricky. If you are on a MacOSX, you might need to have XCode and its tools installed. Also, on Windows, you may need to have some of the .NET Framework properly installed to build that native module. I don’t want to talk about that part of the story to avoid distraction from the main story’s idea.

Conclusion

With that stack, every React web developer can build desktop solutions collecting and storing data into an improved data source once compared to the simple and limited local storage.

I hope you all enjoyed it. You can check the repository at https://github.com/fmacedoo/ers-stack

Thanks!