Comments URL: https://news.ycombinator.com/item?id=43114031

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=43005881

Points: 4

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=42970545

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=42709939

Points: 13

# Comments: 10

DynamoDB is a pain in the ass if you want to do too many relational or arbitrary queries. It's not for data exploration.

It is my favourite database though (next to S3)! For cases where my queries are pretty much known upfront, and I want predictable great performance. As Marc Brooker wrote in [1], "DynamoDB’s Best Feature: Predictability".

I consistently get single digit millisecond GETs, 10-15ms PUTs, and a few more milliseconds for TransactWriteItems.

Are you able to complex joins? No. Are you able to do queries based on different hash/sort keys easily? Not without adding GSIs or a new table. The issue in the past few years was the whole craze around "single-table design". Folks took it literally as having to shove all their data in a single table, instead of understanding the reason and the cases that worked well. And with ongoing improvements of DynamoDB those cases were getting fewer and fewer over time.

But, that's what tradeoffs are about. With on-demand tables, one-shot transactions, actually serverless storage/scaling, and predictable performance you get very, very far.

1. https://brooker.co.za/blog/2022/01/19/predictability.html

Comments URL: https://news.ycombinator.com/item?id=42672724

Points: 82

# Comments: 60

Comments URL: https://news.ycombinator.com/item?id=42665862

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=42621296

Points: 2

# Comments: 1

Looking forward to seeing the more powerful additions to Hurl coming soon!

The pitch line is: "Skybear.NET is a managed platform automating Synthetic HTTP API testing."

At the moment, the main source file format supported for your API tests are Hurl.dev files [1]. Hurl is a CLI tool wrapping `curl` and it's really awesome. At least check that out :)

I am not affiliated directly with the Hurl CLI tool, and the platform I am building provides full Hurl compatibility. I have been using Hurl for a few years now [2], and use it for my API testing, for orchestrating a bunch of HTTP APIs, and in general whenever I need to do anything with HTTP requests, I reach for Hurl.

You can try without signup the basic execution feature with the free Open Editor [3], but for full functionality (retaining responses and cron triggers) you need a signed in account, even free.

The Skybear.NET platform:

1. Has Hurl Compatibility, so take your local scripts and run them on the cloud as well. No changes needed.

2. Provides managed infrastructure for authoring, storing, and most importantly executing your Hurl scripts, that automatically scales to handle as many script runs as you need.

3. Generates detailed reports from your tests execution, automatically persisting requests and response bodies for introspection in the future, and with automatic insights coming up soon.

4. Supports multiple ways of triggering execution of your scripts, including periodic executions, and on-demand HTTP triggers enabling integration with your CICD pipelines.

Most importantly, it eliminates excessive per-request/per-step/per-check charges, leading to substantial cost-savings for complex multi-step API tests covering complete user-journeys. I consider a "script project run" to be the main unit in my pricing, which includes execution of all the source files of the script project, which can be tens or hundreds of requests.

I am starting to document some of the architecture of the platform as well [4], but in a nutshell, all your data is encrypted inside the application before stored on AWS (S3, DynamoDB, also encrypting at rest) [5], the control plane runs on Hetzner and AWS EC2, and the execution servers running your scripts run on Fly and soon on AWS EC2 (for some plans).

Future plans depend a lot on feedback from users. I already have a long list of things I personally want to have, but as more users start using I would like to see user needs influencing the roadmap more.

Some upcoming features: 1. Insights and metric graphs for historical tracking of your tests (per project, per file, per request URL). 2. Automatic generation of tests based on OpenAPI schemas, HAR files, etc. 3. Export API of all the data and reports for your own consumption. 4. OTEL traces generated per script run, exportable and sent to APM products.

Thank you, and I hope you find it interesting too!

Lambros Petrou

1. https://hurl.dev

2. https://www.lambrospetrou.com/articles/hurl/

3. https://www.skybear.net/scripts/open-editor/

4. https://www.skybear.net/docs/getting-started/what-is-skybear...

5. https://www.lambrospetrou.com/articles/encryption/

Comments URL: https://news.ycombinator.com/item?id=42488710

Points: 6

# Comments: 2

It's a simple Markdown file, versioned on my own Gitea instance.

The worklog contains all notes about everything I spend my time at work. That is project work, meetings, discussions, todos, long-term todos and investigations, and anything I need to be able to check back later.

I cannot count the number of times I went back and searched this file to find information that others forgot, the meeting notes did not capture, and in general things that I need.

Keeping this kind of log makes performance reviews trivial too. Just scroll through the worklog for the period you want, copy paste bullet points, and then spend some time cleaning them up and rewriting them as necessary.

If anyone does not keep a worklog, start now :)

1. https://www.lambrospetrou.com/articles/the-worklog-format-1/

Soon, I will be adding analytics, insights, and automatic test generation features.

I have been working for a year on it, and will keep working on it for many years to come, since I am using it myself a lot anyway.

Comments URL: https://news.ycombinator.com/item?id=39427676

Points: 3

# Comments: 0

I dive into the different steps of the CI/CD flywheel, including local code authoring, running CI jobs on pull-requests, deploying and verifying on staging (preproduction) environments, and finally deploying and verifying in production.

Then, I try to showcase the business and technical benefits of a proper CI/CD pipeline.

Busines benefits: - Ship value to customers more often - Earn and retain customer trust - Fast experimentation feedback loop - Attract the right talent - Cost reduction

Technical benefits: - Code quality - Comprehensive tests - Automate repetitive tasks for reproducibility - Build once, use everywhere - Controlled rollouts and faster Mean Time To Resolution (MTTR)

But, at least, you have standardised pools of coding questions, standardised pools of system design questions, and a standardised feedback form.

The interviewer varies a lot though... And makes all the difference when you have an inexperienced one, or someone that doesn't care.

>I can only assume the author has not interviewed many candidates.

I did more than 100 interviews so far.

>I've lost count of how many tenured engineers I've interviewed who could not write basic code or explain basic programming concepts. Things that a practicing programmer would encounter every week.

Where did I say that I agree with this statement. This is what other engineers claim, and as you pointed out being said many times.

I am totally against this claim as well. I do think that those tenured engineers should be interviewed for basic coding skills too. Just last month I had a staff+ engineer not being able to write a DFS...

That part in the article is ironic, hence why I said that I didn't want to make it a discussion about the fact that we have these coding interviews, and to "Get over it!" :)

These are a given. You should know these.

When I said I cannot memorize solutions, I refer to memorizing solutions to specific Leetcode problems. Doing that for 1-2 problems per main area is doable, but anything more than that is quite hard.

Absolutely :) I have that item explicitly in my article, since it happened to me as well being on both sides of the interview process.

It's very unfortunate when communication is problematic accent-wise. And it makes judging difficult as well since you are not focusing on the technical merits alone anymore.

>1) don’t expect only questions relevant to the position.

For this, you might have been unlucky with an inexperienced interviewer...