And yeah OpenTelemetry is where lots of the industry is going and so are we. You can already do cool things with us and the collector but we plan on automating a lot and expand on that.
We are still experimenting with pricing and what can be open and closed. To be completely transparent we chose custom domains because we know companies care a lot. When we have more features on the commercial side we can start to chat about supporting it in the open version. Still early in our journey, happy to discuss anything, like a small plan with just custom domains. Would you pay for that?
We totally agree our website is way too wordy and we are working on explaining our vision through various ways. Screenshots of course, but also things like short videos. We actually just did one of our quickstart https://youtu.be/XkVxYaHsDyY. It’s not perfect but we will get there:-)
Yes that is frustrating indeed. On top of paying your external vendor, you are punished by the egress cost you have to pay to your infrastructure cloud provider. This is one of the problems we wanted to solve. Feel free to contact me [email protected].
Yes! We will be having features that you have to pay a subscription for. It starts with the usual suspects: custom SSO, custom domains, and authorization - things that we would be hosting as an ongoing service for customers. Most features will be open when we create them -- this is near and dear to our hearts -- it’s important our users can be successful with the OSS version. Over time, the commercial features will also flow into the open as we release new proprietary ones. Our commercial features will be public in our repo, under a commercial license.
We will also have a managed version where we deploy and maintain it for the customer in a cloud account they provide us.
Nobody said we gave up on continuous integration. Quite the contrary! We use jenkins and other CI tools on a daily basis.
Once we have tools to build debian packages easily in a controlled environment (containers), the CI server will be able to use the same tools to build and test the final package. The advantage here is that a developer can test the whole workflow and build local test/dev packages with the same tools and environment as the CI server.
1.
Ok so when is it appropriate/useful to use the power of embedded php (in html) instead of templates? Just for learning the first couple of hello worlds?
In my experience it becomes a mess to manage when you start having more than one commiter and more than a couple of lines of code.
2.
You don't have to be a command line expert to start using it. All the books at http://learncodethehardway.org/ show that command line can be integrated in the language learning process seamlessly. No reason to be terrified of it, on the contrary, new coders should embrace it as soon as possible.
Yes you can get up and running quickly with php, but my comment was mostly about the fact that it is not much slower in other languages (most of the time not slower at all).
And yes I did a lot of PHP but that was 5-6 years ago. I know things have changed a lot since then but the language still has a lot of the same flaws.