The power of 2 random choices
Getting started with WebAssembly
wat2js - Compile WebAssembly .wat files to a common js module
WebAssembly spec - WebAssembly Specification
Some examples modules
blake2b - Blake2b implemented in WASM
Follow Mathias Buus on GitHub. He’s has published quite a few interesting things about WebAssembly.
Successor to xpath-object-transform
camaro is an utility to transform XML to JSON, using Node.js binding to native XML parser pugixml, one of the fastest XML parser around.
- Faster. A lot faster.
- Building time is also faster.
- Mostly backward compatible with
xpath-object-transform. I haven’t cover all the cases though.
- pre-built binaries included for some distro. Will include more in the future.
This chapter describes various performance tricks that allowed the author to write a very high-performing parser in C++: pugixml. While the techniques were used for an XML parser, most of them can be applied to parsers of other formats or even unrelated software (e.g., memory management algorithms are widely applicable beyond parsers).
Found out about this gem, recommended by the author of “Writing a Really, Really Fast JSON Parser”. This is a really good post as well.
Very young but interesting project.
Might save you from introducing something new your project just for full text search (chances are you probably already have Redis in your tech stack)
Here’s a dockerfile for Redis 4.0 RC3 and Redisearch 0.16 for you to fiddle with.
- The image is based on glibc for wide compatibility
- Using apt package manager for access to large number of packages
- Quicker security updates
Even though there are many complaints about
glibc, it’s still very widely-adopted.
I would hate to debug building libraries with
musl-libc. It’s just not worth it.
Using alpine as base Docker image
I recently updated all of my personal Dockerfiles that I have for multiple purposes to use
alpine as base image.
Prior this, I just use
ubuntu as the base image and don’t have much care about built-images size. However, using Kubernetes, having small images size can make rolling out update speed much faster.
Some tips for reducing Docker image size that I found during my research:
- Using smaller base image (alpine, busybox, etc..)
- Remove unnecessary dependencies that you use for compiling stuff after done. (Also remove cache)
- Use few layers as possible. However, I don’t think you should do it blindly just for the shake of small image size and destroy readability. I prefer to keep it simple and clean. Optimize it later for building only.
How to setup twemproxy running on kubernetes.
- Convert this into helm chart.
Setting up traefik as Ingress controller for Kubernetes
Just my own experience setting up traefik as Ingress controller on Kubernetes.
brew install kubernetes-helm
Install traefik chart with helm
Download the default
values.yaml file and edit it depends on your needs. Then issue the below command.
I want to install it to
kube-system namespace hence the
helm install --name my-traefik --namespace kube-system --values values.yaml stable/traefik
If you make a mistake and want to remove it
helm delete --purge my-traefik
--purge if you want to reuse the name previously. Otherwise, helm will complain
release xxx already exists.
Update your app
You will have to create an Ingress, a service and a deployment.
Ingress is a rule to help you setup routing traffic from a domain to your cluster service name
Service will expose your pods to be accessible in the cluster by selector (see example)
Deployment is well .. your app deployment.
It will be a whole lot easier if you see this cheese.yaml file
Download the file and
kubectl create -f traefik.yaml to deploy it to your cluster.
In the example above, i will use the domain
Create a CNAME record of
stilton.example.com to point to your traefik’s ELB public address.
If you have traefik dashboard enabled, you should see new ingress and the pods it distributes load to on the web.
PS: You don’t necessarily use
helm. It just make installing stuff a lot easier.
Add support for abi stable module API (N-API) as “Experimental feature”. The goal of this API is to provide a stable Node API for native module developers. N-API aims to provide ABI compatibility guarantees across different Node versions and also across different Node VMs - allowing N-API enabled native modules to just work across different versions and flavors of Node.js without recompilation.
Great news for native module developers :)