Rowern

For anyone clicking on this for the title; please note that this blog post is pushing hard for the author coaching service.

Some may even call this a disguised ad...

Let's save someone a click: this is an empty shell of a blog post. Not really actionnable and only saying that's hard to secure Kubernetes clusters.

Be really careful with this kind of emailing flow. We were booted off 2 mains email provider because our B2B apps allowed people to send invitation to their colleagues... I'm thinking that big email providers (like Mailchimp) don't even try to understand your usage and largely prefer to ban any non-big players from their network.

I would expand your point to add that another missing key part of dev on big distributed platform is being able to run parts of the system locally. For some shop it is a lot harder than a simple docker-compose (think of envs with 10 or 100 of micro-services), any laptop cannot handle such load and it is critical for devs to work on the machine, otherwise you lose a lot of time with shared dev envs, SSH tunnels or rsync... I agree that CI pipelines are a pain in a distributed system but I heard more complains from devs not being able to test locally some new feature in serviceA that depends on 10 other services + DBs to work.

I won't try to do a TL;DR, but from reading the full article, it seems like he is doing kind of fine right now. He is still sick but he is currently writing a thesis. The article has a really positive vibe to it even though it is a really rare disease.

The issue here is that if you're running in the JS ecosystem you'll definitely want to use other people code (npm package or internal lib), if the subset breaks JS compatibility then you can break a significant amount of code without realising, if it is "only" a TS subset, then you need to make sure that each lib/package you import are compatible. Anyway this does not seem like a good solution.

Looks awesome, bravo to you/the team behind it!

If anyone is looking for a simple way to speedup TS compilation for a big project, we use incremental compilation [1]. It does work pretty well, with some caveats when changing between refactoring branches ;)

[1] https://www.typescriptlang.org/docs/handbook/release-notes/t...

Having worked with Terraform for 3 years, I totally agree!

Hashicorp should put more money into promoting "healthy" terraform tutorials based on real world usage (maybe split for small/medium/large orgs)

My first setup was split into 10-15 repos and it was an nightmare...

Now I have a mono-repo (and some GitlabCI magic to handle different projects) + terragrunt and it so much more stable than my first setup! As with everything, start simple, only change if you hit a wall!

This looks pretty interesting! If anyone is looking for a tool to build a full fledge Back Office I warmly recommend react-admin (https://github.com/marmelab/react-admin/). Been using it for a year now and we went from 0 back office to a feature full one in no time!

So much this.

It looks really beautiful. Well done!

We use react-admin (https://github.com/marmelab/react-admin/) and it was a total life saver to create a backoffice for our app in less than 2 weeks.

Hope this takes off and you can provide some code example for how to use this project for that purpose.

You should probably just say its a tutorial on how to install a PWA (i.e. how to click on the install button).

This issue is from 2016...

Traefik is really cool for most usage, I tried to used it in production and here are some of the shortcoming I found (the 2 first issues are on github):

- If you use DNS for a blue-green deployment, traefik does not honor DNS ttls (because it uses the DNS of go and go might do some caching) so when you do the switch you might still end on the "old" environment

- An error on one of the cool feature: serving error page when your backend returns some HTTP code

- Some configuration options are not documented (but easily found using github search)

I still love this software and I will keep looking at it.

My company has 2 big projects running on HHVM.

Most of the library we used to start our projects (symfony, mongodb to name the biggest) dropped the HHVM compatibility in the middle of development, I can tell you this was a good lesson for me: never take a technology where big vendors drop compatibility.

Having to debug a production error with an HHVM library (which support was dropped), find a fix and then seing it was fixed in the official PHP library 6 months ago hurt a lot...

Another point not in favor of HHVM, it's maintained by them, the roadmap is only known to them and the number of HHVM alternatives to big libraries is near 0.

We are gradually moving away from HHVM (and PHP in general) in favor of NodeJS and TypeScript.

I've been working with gitlab CI for the last year. Here are some of my feedbacks:

- 6 months ago we seriously considered moving away because it was really unstable (even when running on private runners) but now its a lot smoother

- with private runners you can have a very powerful CI without having to manage a master (as Jenkins) for a fraction of the costs (runner with docker-machine on spot instances)

- beware that if your CI flow is more complex than just a simple pipeline to build and deploy your project (we have a project for our code, that then trigger a project for end-to-end tests, that then trigger a deploy to our env) you will need to do a lot of boilerplate code (you will need to manually manage artifacts if they need to be shared between jobs)

- variables from a triggered pipeline should be available through the API and made more visible in the UI

- we do not use kubernetes so eveything CD is off the plate for us (environment and monitoring tab are useless)

- DO NOT USE THE BUILT IN CACHE, it's super slow and will fail unexpectedly (simply do cp to s3 and it will never fail)

- IF YOU USE THE BUILT IN CACHE, parallelism will be hard (you cannot populate part of the cache from a job, another part from another job and in the next step use the result of both cache)

- triggers are weird, its a curl to an API endpoint but it does not use the normal auth mechanism and it will answer with a useless json (please add the project id, variables etc to the result of the trigger it's a must have for anyone that needs to parse the output)

- the gitlab API is top notch except on the CI part...

- be ready to restart some jobs 2-3 times if gitlab is deploying a new version ;)

- be ready to have some random errors that can be fixed by a retry

- it will seem a good idea to run gitlab-runner on every laptop of your team to reduce cost. DO NOT DO THAT, if you are more than 2 in your team the guy in charge of making the CI run (me) will make you restart you docker, delete a specific image, restart gitlab-runner, etc... invest 1 day to setup the docker machine on spot

- please show in some way when a job triggered another one (maybe a section in the YML, or even better check make us populate an env var with a link to the triggered pipeline or anything)

- design your pipeline so that if a part fails you can restart it without breaking everything (I'm looking at you terraform)

This list seem really long but, I have worked with Jenkins and even if more stable the steady improvements and addition to gitlab CI still make it my first choice for my needs.

So I am not the only one to have a slow eployment because re-building AMI and re-provisioning everything takes quite some times.

I also had a difficult time to explain that a prod deploy of 30min (image creation, deploy with blue green) is normal for this kind of inf... Did you face the same thing?