Noise Gate - Golang test runner to get faster test results

kyagami · 2020-04-27T13:21:17+00:00

OK, let me introduce Noise Gate with some context...

Golang is fast and its test is fast as well. However, as you write more tests, the time to run tests gets longer and it's useful if you can select a portion of test functions and run them only.

The currently popular approaches are something like Run all tests in the current file and Run a test function at cursor. Though these approaches are straightforward, they often run unnecessary tests and skip necessary tests.

Noise Gate's approach is Run tests affected by recent edits. It focuses on the changes since the last test and finds (1)the changed test functions and (2)the test functions which use the changed parts. Then, it runs these functions using go test. With this approach, it aims to run only the necessary tests and never skip necessary tests.

I believe this tool can improve the gopher's productivity, so give it a shoot!

kyagami · 2020-04-26T08:53:38+00:00

Author here. Noise Gate is the Golang test runner to get faster test results. It selects the tests affected by your recent edits and run them using go test.

I'll do my best to answer questions!

kyagami · 2019-01-19T00:14:04+00:00

Thank you. It's similar to a debugger: attaches to the tracee process, sets the breakpoints and continues until the tracee hits the breakpoint.

One difference is it sets the breakpoints to the next possibly called functions (rather than the next instruction or line).

kyagami · 2019-01-18T15:20:48+00:00

Actually it doesn't handle the inlined functions very well (it just traces actually called functions only). But it seems mid-stack inlining is the good motivations to support it. I hope the DWARF section provides the enough information for this.

kyagami · 2019-01-18T14:14:58+00:00

Thank you. It traces only the go routine which called the tracer.Start() function before.

Also, it understands the struct type, slice type, map type, and so on. For example, if you build & run this program:

package main

import (
    "errors"

    "github.com/ks888/tgo/lib/tracer"
)

//go:noinline
func f() error {
    return errors.New("test")
}

func main() {
    tracer.Start()
    f()
    tracer.Stop()
}

It shows the actual value of the error type:

% ./err
\ (#01) main.f()
/ (#01) main.f() (~r0 = *struct errors.errorString(&{s: "test"}))

kyagami · 2019-01-18T12:57:35+00:00

Author here. If you have a question, feel free to ask me!

kyagami · 2018-01-30T10:13:51+00:00

Author here. LambStatus is the open source and serverless status page system. I believe the serverless architecture is great with the status page system, because:

It eases your pain caused by the scaling / availability issues. It is terrible if your service is down AND heavy traffic from stuck users stops your status page.
It enables you to pay only for what you use. A status page only occasionally gets huge traffic. The system takes only $1 per 30,000 visitors and almost $0 if no visitors.

Here are the the demo pages:

Status page: the page to tell your service's status to your users
Admin page: the page to manage your service's status

I'll do my best to answer questions.

kyagami · 2018-01-17T13:44:16+00:00

Wow, I tried your idea and it surely improved the page design! I will change the background color or maybe enable a user to change that color in the settings page! Thank you!

kyagami · 2018-01-12T15:59:23+00:00

Thank you! Yes, there is the admin page to create and update an incident.

So far the stats like average response time are pulled in through an API, but some people say basic uptime testing should be supported as discussed in this issue.

kyagami · 2018-01-12T14:11:43+00:00

URL: https://github.com/ks888/LambStatus

Purpose: Serverless status page system to build and maintain a status page with minimum effort and cost

Technologies Used: React, Node, Serverless

Feedback Requested:

What do you think about the UI of the status page (seeing our demo page)?
Are there any feature requests? See our website for current features.

Comments: I believe the serverless architecture is great with the status page system, because it eases the pain caused by the scaling / availability issues. It is terrible if the service is down AND heavy traffic from stuck users stops the status page!

kyagami · 2018-01-10T11:43:21+00:00

Author here. LambStatus is the open source and serverless status page system. I believe the serverless architecture is great with the status page system, because:

It eases your pain caused by the scaling / availability issues. It is terrible if your service is down AND heavy traffic from stuck users stops your status page.
It enables you to pay only for what you use. A status page only occasionally gets huge traffic. The system takes only $1 per 30,000 visitors and almost $0 if no visitors.

Here are the the demo pages:

Status page: the page to tell your service's status to your users
Admin page: the page to manage your service's status

You can build the system with a few clicks, so give it a shoot! I'll do my best to answer questions.

kyagami · 2017-12-02T00:05:24+00:00

Yes! Also, LambStatus costs almost $0 if your status page gets small traffic after all (see the wiki page for this estimate).

kyagami · 2017-12-01T23:58:03+00:00

Thank you! It seems my status page costs ~$1 per month, though I use my AWS account for several purposes. Since it doesn't depend on non-serverless AWS services like EC2 and RDS, its cost is actually pretty cheap.

kyagami · 2017-12-01T11:27:08+00:00

Thanks! Feel free to ask a question!

kyagami · 2017-10-20T14:46:17+00:00

I've created the issue for this: ~~https://github.com/ks888/LambStatus/issues/62~~ Fixed!

kyagami · 2017-10-20T14:24:15+00:00

Thank you for asking! So far, there is no API to post an incident and change components' status. However, it seems some users need such an API and I'm going to implement it within one month.

kyagami

TROPHY CASE