# Go parameters\n GOCMD=go\n GOBUILD=$(GOCMD) build\n GOCLEAN=$(GOCMD) clean\n GOTEST=$(GOCMD) test\n GOGET=$(GOCMD) get\n BINARY_NAME=mybinary\n BINARY_UNIX=$(BINARY_NAME)_unix\n \n all: test build\n build: \n $(GOBUILD) -o $(BINARY_NAME) -v\n test: \n $(GOTEST) -v .\/...\n clean: \n $(GOCLEAN)\n rm -f $(BINARY_NAME)\n rm -f $(BINARY_UNIX)\n run:\n $(GOBUILD) -o $(BINARY_NAME) -v .\/...\n .\/$(BINARY_NAME)\n deps:\n $(GOGET) github.com\/markbates\/goth\n $(GOGET) github.com\/markbates\/pop\n \n \n # Cross compilation\n build-linux:\n CGO_ENABLED=0 GOOS=linux GOARCH=amd64 $(GOBUILD) -o $(BINARY_UNIX) -v\n docker-build:\n docker run --rm -it -v "$(GOPATH)":\/go -w \/go\/src\/bitbucket.org\/rsohlich\/makepost golang:latest go build -o "$(BINARY_UNIX)" -v\n<\/code><\/pre>\n\nLet\u2019s say I like to keep the idea of the DRY rule. So it is handy to declare commonly used commands and variables at the top of the file. And refer to them further in the file.<\/p>\n\n
# Basic go commands\nGOCMD=go\nGOBUILD=$(GOCMD) build\nGOCLEAN=$(GOCMD) clean\nGOTEST=$(GOCMD) test\nGOGET=$(GOCMD) get\n\n# Binary names\nBINARY_NAME=mybinary\nBINARY_UNIX=$(BINARY_NAME)_unix\n<\/code><\/pre>\n\nThe makefile targets are defined bellow labels like \u201c:\u201d. These are executed by make tool if the parameter for make is given. If no parameter is provided to make tool, the first task is executed. In this case the \u201call\u201d task is executed.<\/p>\n\n> make run \/\/ call specific task\n> make \/\/ make tool calls "all" task\n<\/code><\/pre>\n\nBasic commands<\/h2>\n\n
One of the essential parts of the makefile is the build step. Using the variable $(GOBUILD) the \u201cgo build\u201d command is executed. The binary name is defined by \u201c-o $(BINARY_NAME)\u201d and I found useful to switch to the verbose mode with \u201c-v\u201d. With verbose mode, you can see the currently built packages.<\/p>\n\n
build:\n $(GOBUILD) -o $(BINARY_NAME) -v \/\/ expands to: "go build -o mybinary -v"\n<\/code><\/pre>\n\nJust because a lot of us are just lazy, the \u201crun\u201d target is here. The target builds the binary and executes the application consequently.<\/p>\n\n
run:\n $(GOBUILD) -o $(BINARY_NAME) -v .\/...\n .\/$(BINARY_NAME)\n<\/code><\/pre>\n\nNaturally, the test command should be the part of the project makefile. I personally always choose the verbose mode to be able to debug and watch the test run better.<\/p>\n\n
test:\n $(GOTEST) -v .\/...\n<\/code><\/pre>\n\nIf the project uses CI\/CD or just for consistency, it is good to keep the list of dependencies used in packages. This is done by the \u201cdeps\u201d task, which should get all the necessary dependencies by \u201cgo get\u201d command.<\/p>\n\n
deps:\n $(GOGET) github.com\/markbates\/goth\n $(GOGET) github.com\/markbates\/pop\n<\/code><\/pre>\n\nTo wrap up this section of useful commands, the clean command is accommodated into makefile. The \u201crm -f\u201d command is added to remove binary with the custom name in $(BINARY_XXX) variable. Typically another clean-up command could be part of this make section.<\/p>\n\n
clean: \n $(GOCLEAN)\n rm -f $(BINARY_NAME)\n rm -f $(BINARY_UNIX)\n<\/code><\/pre>\n\nCrosscompilation commands<\/h2>\n\n
If the project is intended to run on another platform than the one where it is developed, it is useful to include cross compilation commands to make file. I usually run the binaries on\nLinux platform in the container, so the makefile contains the Linux build.<\/p>\n\n
build-linux:\n CGO_ENABLED=0 GOOS=linux GOARCH=amd64 $(GOBUILD) -o $(BINARY_UNIX) -v\n<\/code><\/pre>\n\nIf your code use C binding you could get stuck a little bit. The issue with CGO is that you need a gcc compatible for given platform. So if the development is done on OSX\/Windows you need to build gcc to be able to compile for Linux. At least for me, the configuration of gcc to cross compile the C code is not so straightforward on OSX. If the CGO is needed, the docker image is the best way how to create Linux build. The only requirement: Docker has to be installed.<\/p>\n\n
docker-build:\n docker run --rm -it -v "$(GOPATH)":\/go -w \/go\/src\/bitbucket.org\/rsohlich\/makepost golang:latest go build -o "$(BINARY_UNIX)" -v\n<\/code><\/pre>\n\nSummary<\/h2>\n\n
This way you can make your go development process more effective and fluent. The makefile used in this post is available here<\/a>. Don\u2019t hesitate to comment or ask questions, I\u2019ll be happy to answer or talk about this. Enjoy!<\/p>\n"},{"title":"Deploy on Clever Cloud with Bitbucket Pipelines","link":"https:\/\/sohlich.github.io\/post\/clever_cloud_pipelines\/","pubDate":"Thu, 31 Aug 2017 05:08:10 +0200","guid":"https:\/\/sohlich.github.io\/post\/clever_cloud_pipelines\/","description":"\n\nThere are a lot of CI tools that are available on the market. These are usualy free for open-source project. Recently I\u2019ve come across the Bitbucket Pipelines<\/a> feature that is free also for private ones, with limitation naturally. It is the CI\/CD tool bounded to Bitbucket repository, that is based on containers.\nIn this post, I\u2019d like to walk through the setup of Pipelines to deploy the build on Clever Cloud<\/a>. The Clever Cloud is PaaS provider, which I have been using for about 2 years. They come up with a lot of platforms, but the best one and my favorite is the Docker. With this one, it is possible to deploy any Docker image.\nFor this post, I\u2019ve chosen the Go application to be deployed on top of the Docker platform, but the same approach could be used with other languages.<\/p>\n\nRepository content<\/h2>\n\n
First, we need to add a Dockerfile to application folder (for the simplicity). The most simple Dockerfile could look like following one.<\/p>\n\n
${PROJECT_FOLDER}\/Dockerfile<\/p>\n\n
FROM golang:latest\n #copy the binary of app\n COPY linux_bin linux_bin\n EXPOSE 8080\n #execute the binary\n ENTRYPOINT [".\/linux_bin"]\n<\/code><\/pre>\n\nThe important step in Dockerfile is the exposing of port 8080. The Clever Cloud requires this port as a default HTTP port. If the application does not respond on this port, the monitor tool evaluates the application as non-working and the deployment fails.<\/p>\n\n
The binary itself will be built during the Pipelines run. We can test the Dockerfile by building the binary. As we are running the binary within the container, it must be compiled for Linux and amd64 architecture.<\/p>\n\n
> GOOS=linux GOARCH=AMD64 go build -o linux_bin -v\n > docker build --rm -t clever_cloud_deploy .\n Sending build context to Docker daemon 42.55MB\n Step 1\/4 : FROM golang:alpine\n Step 2\/4 : COPY linux_bin linux_bin\n Step 3\/4 : EXPOSE 8080\n Step 4\/4 : CMD .\/linux_bin\n Successfully built 692db10e1840\n Successfully tagged clever_cloud_deploy:latest\n > docker run --rm -it clever_cloud_deploy:latest\n<\/code><\/pre>\n\nSo the Dockerfile is OK. Now the Pipelines config file must be created. The easiest way how to do that is to copy the config from bitbucket docs and modify it to fit your needs. (Bitbucket Docs<\/a>)<\/p>\n\n${PROJECT_FOLDER}\/bitbucket-pipelines.yml<\/p>\n\n
image: golang:latest\n pipelines:\n default:\n - step:\n caches:\n - gocache # custom golang cache\n script: # Modify the commands below to build your repository.\n - PACKAGE_PATH="${GOPATH}\/src\/bitbucket.org\/${BITBUCKET_REPO_OWNER}\/${BITBUCKET_REPO_SLUG}"\n - mkdir -pv "${PACKAGE_PATH}"\n - tar -cO --exclude-vcs --exclude=bitbucket-pipelines.yml . | tar -xv -C "${PACKAGE_PATH}"\n - cd "${PACKAGE_PATH}"\n - go get -v\n - go build -o linux_bin -v\n - go test -v\n\n<\/code><\/pre>\n\nDeployment to Clever Cloud<\/h2>\n\n
The deployment of an application to Clever Cloud is done via push to the git repository. The push to the master branch invokes the deployment on the provider side. The Docker platform was chosen so the Dockerfile must be the essential part of pushed changes. Naturally, all the files used in Dockerfile are needed. The deployment on the provider side, in fact, consists of the Docker file build and start of the container based on the created docker image.<\/p>\n\n
SSH Keys<\/h3>\n\n
To be able to push into the Clever Cloud repository, the SSH public key must be provided. The existing key could be added or you can generate a new one in Bitbucket repository (Settings \u2192 Pipelines \u2192 SSHKeys) and configure it to be allowed to use in Clever Cloud (see Clever Cloud settings).<\/p>\n\n
Clever Cloud repository and config<\/h3>\n\n
Each application in Clever Cloud has so called \u201cdeployment URL\u201d defined in information tab in the Clever Cloud console (administration page). The URL is similar to one below.<\/p>\n\n
git+ssh:\/\/git@push-par-clevercloud-customers.services.clever-cloud.com\/app_b5a2def7-ed24-4fde-bcf2-5d0525c2d00b.git\n<\/code><\/pre>\n\nThis URL would be used in Pipelines config file as a remote git repository to push the built files. The deploy than will consist of these steps:<\/p>\n\n
\n- initialize Git repository<\/li>\n
- commit all files needed for Dockerfile build<\/li>\n
- push to remote master branch<\/li>\n<\/ul>\n\n
Before we do that we need to add the push-par-clevercloud-customers.services.clever-cloud.com host to \u201cknown hosts\u201d. This is done via Settings \u2192 SSH \u2192 Known Hosts section.\nAfter this is done the steps described above can be added to Pipelines config file.<\/p>\n\n
${PROJECT_FOLDER}\/bitbucket-pipelines.yml (partial)<\/p>\n\n
- git init\n - git config user.name "Pipeline" && git config user.email "pipeline@example.org"\n # Use -f switch to override .gitignore file\n - git add -f linux_bin \n - git commit -m "init"\n<\/code><\/pre>\n\nInitialisation of the repository, configuration of user and email is needed. Without this git refuses to work properly.<\/p>\n\n
Finally, push all the changes to Clever Cloud repo using the \u2014force switch.<\/p>\n\n
git push git+ssh:\/\/git@push-par-clevercloud-customers.services.clever-cloud.com\/app_b5a2def7-ed24-4fde-bcf2-5d0525c2d00b.git master --force\n<\/code><\/pre>\n\nThe complete Pipelines configuration file could look like this.<\/p>\n\n
${PROJECT_FOLDER}\/bitbucket-pipelines.yml<\/p>\n\n
image: golang:latest\n pipelines:\n default:\n - step:\n caches:\n - gocache # custom golang cache\n - xchache # custom golang cache\n - pkgincache # custom golang cache\n script: # Modify the commands below to build your repository.\n - PACKAGE_PATH="${GOPATH}\/src\/bitbucket.org\/${BITBUCKET_REPO_OWNER}\/${BITBUCKET_REPO_SLUG}"\n - mkdir -pv "${PACKAGE_PATH}"\n - tar -cO --exclude-vcs --exclude=bitbucket-pipelines.yml . | tar -xv -C "${PACKAGE_PATH}"\n - cd "${PACKAGE_PATH}"\n - go get -v\n - go build -o linux_bin -v\n - go test -v\n - git init\n # Deployment to clever cloud\n - git config user.name "Pipeline" && git config user.email "pipeline@example.org"\n - git add -f linux_bin\n - git commit -m "init"\n - git push git+ssh:\/\/git@push-par-clevercloud-customers.services.clever-cloud.com\/app_b5a2def7-ed24-4fde-bcf2-5d0525c2d00b.git master --force\n<\/code><\/pre>\n\nThat\u2019s it. After your commit arrive to Bitbucket repository the Pipelines run is started, subsequently the build deployed on Clever Cloud. Enjoy!<\/p>\n\n
Link to the sample repository:\nhttps:\/\/bitbucket.org\/rsohlich\/clever_cloud_deploy<\/a><\/p>\n"},{"title":"Angular on Electron, part 2","link":"https:\/\/sohlich.github.io\/post\/angular_electron_2\/","pubDate":"Sun, 20 Aug 2017 20:33:51 +0200","guid":"https:\/\/sohlich.github.io\/post\/angular_electron_2\/","description":"\n\nIn the previous post the bootstrap of Angular project on Electron platform was described. In this one, the process of application packaging will be presented.<\/p>\n\n
One of the benefits of Electron is that it runs on all major platforms. Each platform has naturally its needs regarding to creating the distribution package. Fortunately, the packaging and all that stuff do not need to be done manually. There are few tools which will help you. But first things first.<\/p>\n\n
Get ready<\/h2>\n\n
Before we begin this tutorial there will be one small change to an existing project from part 1. Because the folder “dist” will be used for another purpose, the Angular default build folder will be changed to “build”. This is done by modification of “angular-cli.json” config file. The property “outDir” of “apps” section will change the default output directory.<\/p>\n\n
${PROJECT_FOLDER}\/angular-cli.json:<\/p>\n\n
"apps": [\n {\n ...\n "root": "src",\n "outDir": "build"\n ...}\n ],\n ...\n<\/code><\/pre>\n\nAfter this change, test the configuration by building the project. The folder “build” should be created with all the content. If everything is OK, we are good to go.<\/p>\n\n
> ng build\n > tree build\/\n build\/\n \u251c\u2500\u2500 favicon.ico\n \u251c\u2500\u2500 index.html\n \u251c\u2500\u2500 inline.bundle.js\n \u251c\u2500\u2500 inline.bundle.js.map\n \u251c\u2500\u2500 main.bundle.js\n \u251c\u2500\u2500 main.bundle.js.map\n \u251c\u2500\u2500 polyfills.bundle.js\n \u251c\u2500\u2500 polyfills.bundle.js.map\n \u251c\u2500\u2500 styles.bundle.js\n \u251c\u2500\u2500 styles.bundle.js.map\n \u251c\u2500\u2500 vendor.bundle.js\n \u2514\u2500\u2500 vendor.bundle.js.map\n<\/code><\/pre>\n\nAssets packaging<\/h2>\n\n
All the assets of application need to be bundled in the distribution somehow. Naturally there are several ways how to accomplish that. The first option is to bundle the files ( js, css bundles) as they are. Your install folder that will contain the build folder with all the files. Sometimes it is better to hide the raw files from user. So the next option is to use archive. As this si preferred way, the asar archive were designed.<\/p>\n\n
Asar archive<\/em><\/p>\n\nThe asar archive (https:\/\/github.com\/electron\/asar<\/a>) is tar-like format very easy to use. Following example demonstrates the basic usage.<\/p>\n\n > npm install -g asar\n > asar pack app app.asar\n<\/code><\/pre>\n\nThe benefit of asar archive is that it could be read as simple as a folder in the filesystem. One way how to achieve it is via Node API. (https:\/\/electron.atom.io\/docs\/tutorial\/application-packaging\/#using-asar-archives<\/a>)<\/p>\n\n const fs = require('fs')\n fs.readdirSync('\/path\/to\/example.asar')\n<\/code><\/pre>\n\nThere is more. The Electron BrowserWindow class provides the ability to access the archive too. So it can load the “index.html” file in the application the common way via the BrowserWindow#loadURL method. In this case, the “__dirname” would be the path to the .asar file.<\/p>\n\n
var path = require('path');\n var url = require('url');\n win = new BrowserWindow({ width: 1280, height: 960 });\n \/\/ __dirname is a current working directory\n win.loadURL(url.format({\n pathname: path.join(__dirname, 'build', 'index.html'),\n protocol: 'file:',\n slashes: true\n }));\n<\/code><\/pre>\n\nNow after the packaging and the ways how to use the asar were described, let’s move to an installer. Don’t worry you would not need to create the archives and config files manually. The tools for this purpose are there for you.<\/p>\n\n
Electron builder<\/h2>\n\n
For this tutorial, the electron-builder<\/a> tool will be used. The utility simplifies the creation of distribution package for all major platforms, even the cross platform build is possible.<\/p>\n\n npm install electron-builder --save-dev\n<\/code><\/pre>\n\nThe electron-builder tool needs a little bit of configuration, so the final changes in “package.json” file looks like this (This is a minimal configuration)\n${PROJECT_FOLDER}\/package.json<\/p>\n\n
"author": {\n "name": "Radomir Sohlich",\n "email": "sohlich@example.com"\n },\n "description": "Example application.",\n "devDependencies": {\n "electron-builder": "^19.22.0",\n },\n "build": {\n "appId": "com.example.app",\n "files": [\n "main.js",\n "build"\n ],\n "mac": {\n "category": "productivity"\n }\n }\n<\/code><\/pre>\n\nThe build->files section defines which files\/folders will be included in asar archive. The archive works as the application folder. The electron executes the main.js directly from the archive. The build folder contains application build with index.html and bundles. The “author” and “description” properties are not mandatory, but it is always better to provide this info. (The electron-builder will produce less warning messages :) )<\/p>\n\n
The final step is to add a npm command to run the electron-builder build.<\/p>\n\n
${PROJECT_FOLDER}\/package.json<\/p>\n\n
"scripts": {\n "dist": "build --mac"\n },\n<\/code><\/pre>\n\nThe “dist” command will build the application and subsequently build a distribution package. In this case, the MacOS is configured. The platform is defined by the switch. The available values are in the following figure. (stolen from project documentation https:\/\/github.com\/electron-userland\/electron-builder#cli-usage<\/a>)<\/p>\n\n --mac, -m, -o, --macos Build for macOS, accepts target list (see\n https:\/\/goo.gl\/HAnnq8). [array]\n --linux, -l Build for Linux, accepts target list (see\n https:\/\/goo.gl\/O80IL2) [array]\n --win, -w, --windows Build for Windows, accepts target list (see\n https:\/\/goo.gl\/dL4i8i) [array]\n<\/code><\/pre>\n\nTo execute the build, call the command in terminal and the output should look like this.<\/p>\n\n
> npm run dist\n > electron_app@0.0.0 distmac \/Users\/radek\/Junk\/electron_app\n > ng build && build --mac\n \n Hash: ee6c31ccdab8735b740c\n Time: 10199ms\n chunk {0} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 177 kB {4} [initial] [rendered]\n chunk {1} main.bundle.js, main.bundle.js.map (main) 5.27 kB {3} [initial] [rendered]\n chunk {2} styles.bundle.js, styles.bundle.js.map (styles) 10.5 kB {4} [initial] [rendered]\n chunk {3} vendor.bundle.js, vendor.bundle.js.map (vendor) 1.89 MB [initial] [rendered]\n chunk {4} inline.bundle.js, inline.bundle.js.map (inline) 0 bytes [entry] [rendered]\n electron-builder 19.22.1\n No native production dependencies\n Packaging for darwin x64 using electron 1.7.5 to dist\/mac\n Building macOS zip\n Building DMG\n Application icon is not set, default Electron icon will be used\n<\/code><\/pre>\n\nAfter the successful command run, the dist folder should be created in the working directory and the installer should be there.<\/p>\n\n
dist\/\n --- electron_app-0.0.0-mac.zip\n --- electron_app-0.0.0.dmg\n --- mac\n --- electron_app.app\n<\/code><\/pre>\n\nThe “electron_app.app\/Resources” folder contains the asar archive with “app.asar” file. That is our bundled application. If you need to debug, what is packed into “app.asar” file and what is included in the installer. The “build –dir” command could be used. It will create only the expanded distribution folder (same as dist\/mac).<\/p>\n\n
Note:\nIf you encounter the error by executing the “build –dir” command.<\/p>\n\n
Error: Cannot find electron dependency to get electron version\n<\/code><\/pre>\n\nThe electron dependency need to be add to project.<\/p>\n\n
npm install electron --save-dev\n<\/code><\/pre>\n\nThe repository with example project https:\/\/github.com\/sohlich\/angular_on_electron<\/a><\/p>\n\nSeries:<\/h3>\n\n\n- Angular on Electron, part 1<\/a><\/li>\n
- Angular on Electron, part 2<\/a><\/li>\n<\/ul>\n"},{"title":"Angular on Electron, part 1","link":"https:\/\/sohlich.github.io\/post\/angular_electron\/","pubDate":"Sat, 29 Jul 2017 08:48:41 +0200","guid":"https:\/\/sohlich.github.io\/post\/angular_electron\/","description":"\n\n
Today it is possible to have almost all the applications as a service online. Literally you don’t have to install any of it on you computer. Even if this is possible, but for me it is still more comfortable to have a dedicated desktop application. I believe I’m not the only one. There are a lot of ways how to create a desktop application. Utilizing the native frameworks like Qt, WxWidgets is always an option. For Java people, there are two useful options: swing and java fx.\nBut for me as web developer, though java based, it means to learn a new library or whole framework, all its features and pitfalls… But what If anybody tells you that you can use your good “old” javascript and HTML? Me, I\u2019m totally IN.<\/p>\n\n
So here comes the Electron platform (https:\/\/electron.atom.io\/<\/a>) based on Chromium browser. It provides presentation layer and runtime for your application.\nThe Electron accompanied by Angular framework is a very solid foundation for desktop application development in most of use cases. By the way lot of well known applications are based on electron: VS Code, Slack, WhatsApp…<\/p>\n\nI’ll try to show you how to start your own project, or “Electronify” the existing one.<\/p>\n\n
Bootstrap your project<\/h1>\n\n
Using an Angular CLI generate a new application and test the first run. After following command you should be able to see the result in the browser on URL http:\/\/localhost:4200<\/a>.<\/p>\n\n> ng new electron_app\n> ng serve\n<\/code><\/pre>\n\nAdd main file for the electron called main.js<\/p>\n\n
${PROJECT_FOLDER}\/main.js:<\/p>\n\n
const { app, BrowserWindow } = require('electron');\n \n \/\/ Executes when the application \n \/\/ is initialized.\n app.on('ready', function() {\n console.log('Starting application!');\n \/\/ Create browser window \n \/\/ with given parameters\n mainWindow = new BrowserWindow({ width: 1280, height: 960 });\n mainWindow.loadURL("http:\/\/localhost:4200");\n \n \/\/ It is useful to open dev tools\n \/\/ for debug.\n mainWindow.webContents.openDevTools();\n mainWindow.on('closed', function() {\n mainWindow = null;\n });\n });\n \n \/\/ Defines the behavior on close.\n app.on('window-all-closed', function() {\n app.quit();\n });\n<\/code><\/pre>\n\nAnd update the package.json file by few additional properties:\n${PROJECT_FOLDER}\/package.json:<\/p>\n\n
{\n "name": "electron_app",\n "version": "0.0.0",\n "main": "main.js",\n "license": "MIT",\n "scripts": {\n "ng": "ng",\n "start": "ng serve",\n "build": "ng build",\n "test": "ng test",\n "lint": "ng lint",\n "e2e": "ng e2e"\n },\n "private": true,\n "dependencies": {\n "@angular\/animations": "^4.0.0",\n "@angular\/common": "^4.0.0",\n "@angular\/compiler": "^4.0.0",\n "@angular\/core": "^4.0.0",\n "@angular\/forms": "^4.0.0",\n "@angular\/http": "^4.0.0",\n "@angular\/platform-browser": "^4.0.0",\n "@angular\/platform-browser-dynamic": "^4.0.0",\n "@angular\/router": "^4.0.0",\n "core-js": "^2.4.1",\n "rxjs": "^5.4.1",\n "zone.js": "^0.8.14"\n },\n "devDependencies": {\n "@angular\/cli": "1.2.4",\n "@angular\/compiler-cli": "^4.0.0",\n "@angular\/language-service": "^4.0.0",\n "@types\/jasmine": "~2.5.53",\n "@types\/jasminewd2": "~2.0.2",\n "@types\/node": "~6.0.60",\n "codelyzer": "~3.0.1",\n "jasmine-core": "~2.6.2",\n "jasmine-spec-reporter": "~4.1.0",\n "karma": "~1.7.0",\n "karma-chrome-launcher": "~2.1.1",\n "karma-cli": "~1.0.1",\n "karma-coverage-istanbul-reporter": "^1.2.1",\n "karma-jasmine": "~1.1.0",\n "karma-jasmine-html-reporter": "^0.2.2",\n "protractor": "~5.1.2",\n "ts-node": "~3.0.4",\n "tslint": "~5.3.2",\n "typescript": "~2.3.3"\n }\n }\n<\/code><\/pre>\n\nI recommend to install the electron platform globaly with command:<\/p>\n\n
> npm install -g electron\n<\/code><\/pre>\n\nThe first simple manual run could be done by calling following commands (these must be run in separate terminal windows as the \u201cng serve\u201d is blocking)<\/p>\n\n
> ng serve\n > electron .\n<\/code><\/pre>\n\nCommand \u201cng serve\u201d will start development server on http:\/\/localhost:4200<\/a>, you can notice the this url is used in main.js file. The “electron .” will start the electron app by executing the main.js file.<\/p>\n\nYou can use concurrently<\/a> tool to run these two commands concurrently. Also it can be incorporated to package.json file as an npm script.<\/p>\n\nnpm install -g concurrently\n<\/code><\/pre>\n\n${PROJECT_FOLDER}\/package.json<\/p>\n\n
"scripts": {\n ...\n "electrondev": "concurrently -k \\"ng serve\\" \\"electron .\\""\n },\n<\/code><\/pre>\n\nServing static files<\/h1>\n\n
Serving angular application via development server is not very comfortable and permanent solution. Better approach is serving a static files from the build output folder (let’s call it distribution folder). The main.js file need to be changed to open the index.html file located in distribution folder of your angular application.<\/p>\n\n
${PROJECT_FOLDER}\/main.js<\/p>\n\n
const { app, BrowserWindow } = require('electron');\n path = require('path');\n url = require('url');\n app.on('ready', function() {\n console.log('Starting application!');\n mainWindow = new BrowserWindow({ width: 1280, height: 960 });\n \n \/\/ Change loadUrl to load index.html\n \/\/ using url and path package \n \/\/ to format the file url\n mainWindow.loadURL(url.format({\n \/\/__dirname is the current working dir\n pathname: path.join(__dirname, 'dist', 'index.html'),\n protocol: 'file:',\n slashes: true\n }));\n \n \/\/ Opens dev tools\n mainWindow.webContents.openDevTools();\n mainWindow.on('closed', function() {\n mainWindow = null;\n });\n });\n app.on('window-all-closed', function() {\n app.quit();\n });\n<\/code><\/pre>\n\nAfter you open electron you will receive \u201cFailed to load resource\u201d error.\nThere is one step missing to get the change work.\n![](\"https:\/\/d2mxuefqeaa7sj.cloudfront.net\/s_F68920300BC018EB3E1E88614B689BAD376E939D730AA4BF30888F46A4DF2F8A_1501387336733_image.png\"\/)
<\/p>\n\n
The one small change that need to be done is in your index.html file. We need to define the base for the file as absolute but from the actual working directory like \u201c.\/\u201d. This is done in
${PROJECT_FOLDER}\/index.html :<\/p>\n\n
<!doctype html>\n <html lang="en">\n <head>\n <meta charset="utf-8">\n <title>Electron<\/title>\n <!-- Change the href attribute \n to reference to cur. working dir -->\n <base href=".\/">\n <meta name="viewport" content="width=device-width, initial-scale=1">\n <link rel="icon" type="image\/x-icon" href="favicon.ico">\n <\/head>\n <body>\n <app-root><\/app-root>\n <\/body>\n <\/html>\n<\/code><\/pre>\n\nThat’s it. Desktop application with Angular. The same approach could be used with other JS frameworks or just pure static HTML. I was excited how easy it is.<\/p>\n\n
The repository with example project https:\/\/github.com\/sohlich\/angular_on_electron<\/a><\/p>\n\nSeries:<\/h3>\n\n\n- Angular on Electron, part 1<\/a><\/li>\n
- Angular on Electron, part 2<\/a><\/li>\n<\/ul>\n"},{"title":"Streaming JSON with Jackson","link":"https:\/\/sohlich.github.io\/post\/jackson\/","pubDate":"Wed, 08 Feb 2017 20:27:44 +0100","guid":"https:\/\/sohlich.github.io\/post\/jackson\/","description":"
Sometimes there is a situation, when it is more\nefficient to parse the JSON in stream way.\nEspecially if you are dealing with huge input\nor slow connection. In that case the JSON need to be read\nas it comes from input part by part.\nThe side effect of such approach is that you are able to\nread corrupted JSON arrays in some kind of comfortable way.<\/p>\n\n
Well known Jackson library (https:\/\/github.com\/FasterXML\/jackson-core<\/a>)\nprovides so called stream API to handle it.\nThe parsing of stream is possible via\nJsonParser object, which uses token approach.<\/p>\n\nInputStream is = new FileInputStream("data.json");\nJsonFactory factory = new JsonFactory();\nJsonParser parser = factory.createJsonParser(is);\n<\/code><\/pre>\n\nTo simplify the approach, the combination of ObjectMapper\nwith sequetial reading of JSON data could be used.The code of the\ncomplete solution could be like:<\/p>\n\n
public void tryParse(InputStream is) throws IOException {\n\t\tJsonFactory factory = new JsonFactory();\n\t\tJsonParser parser = factory.createJsonParser(is);\n\t\tObjectMapper mapper = new ObjectMapper()\n\t\t\t\t.configure(DeserializationConfig.Feature.FAIL_ON_UNKNOWN_PROPERTIES,false);\n\n\t\tJsonToken token = parser.nextToken();\n\t\t\n \t\/\/ Try find at least one object or array.\n\t\twhile (!JsonToken.START_ARRAY.equals(token) && token != null && !JsonToken.START_OBJECT.equals(token)) {\n\t\t\tparser.nextToken();\n\t\t}\n\n\t\t\/\/ No content found\n\t\tif (token == null) {\n\t\t\treturn;\n\t\t}\n\n\t\tboolean scanMore = false;\n\n\t\twhile (true) {\n\t\t\t\/\/ If the first token is the start of obejct ->\n\t\t\t\/\/ the response contains only one object (no array)\n\t\t\t\/\/ do not try to get the first object from array.\n\t\t\ttry {\n\t\t\t\tif (!JsonToken.START_OBJECT.equals(token) || scanMore) {\n\t\t\t\t\ttoken = parser.nextToken();\n\t\t\t\t}\n\t\t\t\tif (!JsonToken.START_OBJECT.equals(token)) {\n\t\t\t\t\tbreak;\n\t\t\t\t}\n\t\t\t\tif (token == null) {\n\t\t\t\t\tbreak;\n\t\t\t\t}\n\n\t\t\t\tObject node = mapper.readValue(parser, mappedClass);\n\t\t\t\t\n\t\t\t\t\/\/YOUR CODE TO HANDLE OBJECT\n\t\t\t\t\/\/...\n\n\n\t\t\t\tscanMore = true;\n\t\t\t} catch (JsonParseException e) {\n\t\t\t\thandleParseException(e);\n\t\t\t\tbreak;\n\t\t\t}\n\t\t}\n\t}\n<\/code><\/pre>\n"},{"title":"Nats Proxy Framework","link":"https:\/\/sohlich.github.io\/post\/natsproxy\/","pubDate":"Sun, 28 Aug 2016 08:48:41 +0200","guid":"https:\/\/sohlich.github.io\/post\/natsproxy\/","description":"\n\nThe REST to NATS proxy project sohlich\/nats-proxy<\/a> is the micro framework that provides a bridge between HTTP and NATS. To introduce the problem, we first compare the HTTP and NATS communication models. The table below represents the matching of HTTP and NATS concepts and what do they provide.<\/p>\n\n
![](\"https:\/\/sohlich.github.io\/img\/blog\/natsproxy\/natsproxy_rest.png\")
<\/p>\n\n![](\"https:\/\/sohlich.github.io\/img\/blog\/natsproxy\/natsproxy_arch.png\")
<\/p>\n\n![](\"https:\/\/sohlich.github.io\/img\/blog\/natsproxy\/natsproxy_request.png\")
<\/p>\n\n