vmarchaud

Jumping the opportunity:; we make a product that do hyper-personalisation for marketing emails, we do have few customers using SFMC and we tried to think about some use cases with Agentforce but i don't see a lot of useful things. Some customers want to see data about who saw personalisation in tableau/datacloud but again this isn't direct integration with Agentforce but more sending data to any salesforce product. Did you see any pratical use case for Agentforce in SFMC ? Thanks

If someone else doesn't understand why painters would have a problem with Tesla (like me), you might be interested in this: https://www.ifmetall.se/aktuellt/tesla/background-informatio...

They do have a policy to only include free software [1]:

> We only accept formulae that use a Debian Free Software Guidelines license or are released into the public domain following DFSG Guidelines on Public Domain software into homebrew/core.

[1]: https://docs.brew.sh/License-Guidelines

I've written about this specific subject here [0], feel free to reach out or ask them here if you have other questions

[0]: https://vmarchaud.fr/deploying-kubernetes-the-hard-way/

You could do that with Ansible, there's kubespray [0] from the official project to do that. You may want to read [1] starting with [2]. There's also k3s [0] and k0s [4]. I've written about my setup here [5] also if you are interested.

[0]: https://github.com/kubernetes-sigs/kubespray

[1]: https://www.tauceti.blog/

[2]: https://www.tauceti.blog/posts/kubernetes-the-not-so-hard-wa...

[3]: https://k3s.io/

[4]: https://k0sproject.io/

[5]: https://vmarchaud.fr/deploying-kubernetes-the-hard-way/

You can follow [0] which is currently stage 2 to fix this

[0]: https://github.com/tc39/proposal-async-context

I've used OpenTelemetry since it's original alpha in 2020. Originally the main issue i had was supporting tracing across common libraries (there wasn't a lot of libraries supported back then). Now (and i recently worked with it) i would say is which protocol is supported by which component: your sdk generate spans/metrics in a specific format, then you send that to a collector that accept a range of protocol versions and finally you can send that to your vendor ... but you need to know which protocol/version it supports.

That's not actually something you can do much about considering the sheer size of opentelemetry (both in term of implementation and vendors working on it) and i expect for people implementing nowadays, proto should be pretty stable and my experience should theorically not be the case anymore.

Someone from F5 worked on this with OpenTelemetry [0] for Arrow, another effort was done for Parquet but was dropped [1]

[0]: https://github.com/open-telemetry/oteps/pull/171

[1]: https://github.com/open-telemetry/opentelemetry-proto/pull/3...

We have ~two dozens rented boxes @ OVH in their French datacenters, apart from hardware failures from time to time (1/2 per year) you should be fine, just take that into account while designing the architecture. Also don't expect the support to helps you, they will sometimes but i'll say it's better to not expect it to not be surprised :)

You might be interested into Matt Mochary free books [0], he's a succesfull ceo coach around the valley.

[0]: https://docs.google.com/document/d/1ZJZbv4J6FZ8Dnb0JuMhJxTnw...

Hey, i'm interested in the kind of problems you have run against in those cases if you don't mind sharing them ? My email is in my bio

Not specially something that you cannot do without WASM but at $WORK we are using a WASM build of Skia [0] to render canvas from nodejs.

Why use WASM ? Because we wanted to stay close to our stack (ie. calling wasm from nodejs). Do it work ? Yes, memory consumption is quite heavy though (each WASM module have its own heap that can quickly grow).

However we are looking to directly use Skia now and avoid the overhead of WASM so i think its a nice solution in the beginning but you might want to ditch it later on.

[0]: https://github.com/google/skia/tree/main/modules/canvaskit

We used tsoa where i work but had issues with complex types [0] so one of our dev rewrote a simpler implementation [1] that use ts-morph [2] under the hood.

Not exactly related but we had issues with the official openapi generated so he also wrote a package to codegen typescript client from an openapi file [3]

[0]: https://github.com/lukeautry/tsoa/pulls?q=is%3Apr+sort%3Aupd...

[1]: https://github.com/Eywek/typoa

[2]: https://github.com/dsherret/ts-morph

[3]: https://github.com/Eywek/oatyp

I'm working at a company that does realtime content generation for emails/website, generally those are images but we are trying to do video now. The big problem we have are the cost of bandwith, specially for video (we are speaking about ~20MB video send to 1M users over 2-3h, you can eyeball it at ~2k$ just for the bandwith). So we decided to migrate to dedicated servers (still ongoing), better performance for a fraction of the cost (you can find 80e/month servers with 12cpu/64G ram at OVH for example) and no bandwith cost.

We already had experience with running bare metal infra (hashicorp stack), currently evaluating how to deploy it (currently using GKE). Althrough it should be straight forward since its mostly stateless workload, we it need to be able scale x10 in less than 1h sometimes so we might throw an node autoscaler that provision from cloud.

Disclosure: I contribute to the software mentionned next.

Definitely implement OpenTelemetry [0] instead of specific providers sdk even if promised to have better features. Lock-in is hard to escape when you need ship 2 features for yesterday. However OTel is quite young though (still not GA) so you'll feel some missing features (logs are still WIP for ex).

On the question of where to host the data, on the early days i would recommend to opt (if available) for your cloud platform products (Stackdriver for GCP for ex) since it will be easier to setup. Later on you will be able to easily switch to something better as your needs will evolve.

[0]: https://opentelemetry.io/

I believe there is a little bit of comedy around this. If you look at the repo [0] you'll see funny issues tags (even the tags of the repo themselves), for example "merci mais on s'en branle" which means "thanks but we don't give a fuck".

[0]: https://github.com/soulaklabs/bitoduc.fr

You should checkout the template from YC [0]

[0]: https://www.ycombinator.com/sales_agreement

Interesting post ! From what i've understood you had only one instance of NodeJS, while i agree that Rust is more performant generally, couldn't have you just added more instance ?

In the case of NodeJS, which use the V8 Engine [0], you have access to the diagonistics API [1] that allows you profile your cpu or memory consumption. There are some tools that make that easier (see [2] or [3]) but you often left to interpret the result yourself

[0]: https://v8.dev/

[1]: http://nodejs.org/dist/latest-v12.x/docs/api/inspector.html#...

[2]: https://github.com/davidmarkclements/0x

[3]: https://github.com/vmarchaud/openprofiling-node

PS: Disclamer i wrote one of tool i mentionned above [3]

I've encounted different issues with NodeJS services in the past (and still do) both with CPU bottleneck and Heap allocations. So i wrote openprofiling-node [0] during this summer to help me profile my apps directly in production and export the result in a S3 bucket. I believe it may help someone else here so i'm posting it

[0]: https://github.com/vmarchaud/openprofiling-node

I'm working on the OpenTelemetry JS project and i previously worked a bit on OpenCensus NodeJS.

The aim with both projects (OpenCensus/OpenTelemetry) is the same: having a open source implementation where you can change the exporter (to GCP,AWS,Zipkin,Jeager or anything you want) whenever you like. So Microsoft (or someone else having the API to report data to Azure) could totally implement an exporter for ApplicationInsights. Both projects have a specs [0][1] that are implemented in multiples languages.

Note: OpenTelemetry is just the project that resulted from the merging of OpenTracing and OpenCensus.

[0] https://github.com/census-instrumentation/opencensus-specs [1] https://github.com/open-telemetry/opentelemetry-specificatio...

Hey,

First of all, i like the idea of centralizing the security around GPG in tech teams, there almost no tools that help with that. The first problem that comes to my mind is that we don't understand how you will provide the product, is that a hardware key ? A Desktop client ? For exemple in my case, i've setup yubikey for our devops team, i personally think that it's the best way to have gpg key around. - Do your service/product will work with it ? - If you don't provide a hardware key, how can you provide enough security ?

A great example of tech explanations is krypt.co [0] [1] which provide really example for different roles.

[0] https://krypt.co/developers/ [1] https://krypt.co/devops/