Very nice! We all really need a tool that IT can use to diagnose problems along the path. Like more user friendly nping —tr
Like mtrace/mtr?
Show HN: Sping – An HTTP/TCP latency tool that's easy on the eye
11–20 of 29 posts
Re: Show HN: Sping – An HTTP/TCP latency tool that's easy on the eye
#12> It's easy to install if you have pip. (Available at service-ping-sping on PyPi)
Consider rewriting the program in Go, then you’ll have a statically linked binary that’s much easier to install (less dependencies) and will be much faster too.
Re: Show HN: Sping – An HTTP/TCP latency tool that's easy on the eye
#13> It's easy to install if you have pip. (Available at service-ping-sping on PyPi) Consider rewriting the program in Go, then you’ll have a statically linked binary that’s much easier to install (less dependencies) and will be much faster too.
If that is the objective, there's a few options available; a more pragmatic one is to use a tool that bundles a Python runtime and the application into a single executable, there's a few options there. Rewriting in a different language should always be a last resort given the time investment required.
Re: Show HN: Sping – An HTTP/TCP latency tool that's easy on the eye
#14[dead]
Re: Show HN: Sping – An HTTP/TCP latency tool that's easy on the eye
#15FYI: the final summary gets hidden if the graph writes a frame after the summary is output.
Re: Show HN: Sping – An HTTP/TCP latency tool that's easy on the eye
#16> It's easy to install if you have pip. (Available at service-ping-sping on PyPi) Consider rewriting the program in Go, then you’ll have a statically linked binary that’s much easier to install (less dependencies) and will be much faster too.
If that is the objective, there's a few options available; a more pragmatic one is to use a tool that bundles a Python runtime and the application into a single executable, there's a few options there. Rewriting in a different language should always be a last resort given the time investment required.
> Rewriting in a different language should always be a last resort given the time investment required.
Makes no sense. This is a relatively small program that can easily be rewritten by a large large model like ChatGPT, Claude, Gemini, etc. in a day session.
Re: Show HN: Sping – An HTTP/TCP latency tool that's easy on the eye
#17> It's easy to install if you have pip. (Available at service-ping-sping on PyPi) Consider rewriting the program in Go, then you’ll have a statically linked binary that’s much easier to install (less dependencies) and will be much faster too.
If that is the objective, there's a few options available; a more pragmatic one is to use a tool that bundles a Python runtime and the application into a single executable, there's a few options there. Rewriting in a different language should always be a last resort given the time investment required.
> Rewriting in a different language should always be a last resort given the time investment required.
..or, a refreshing and exciting experience.
Re: Show HN: Sping – An HTTP/TCP latency tool that's easy on the eye
#18> It's easy to install if you have pip. (Available at service-ping-sping on PyPi) Consider rewriting the program in Go, then you’ll have a statically linked binary that’s much easier to install (less dependencies) and will be much faster too.
These days, once you have https://docs.astral.sh/uv/ installed, `uvx --from service-ping-sping sping` is pretty much zero effort to run this software.
Re: Show HN: Sping – An HTTP/TCP latency tool that's easy on the eye
#19Looks nice. I would add a link to the gitlab to the page also, clicking the LICENCE brings me to the source code but other than that there did not seem to be a link . Out of curiosity, did you use LLM's to code this? My gut feeling tells me at minimum the readme was written by one, or maybe it's normal to use emojis everywhere :-) Also I am not meaning to judge it as good or bad, I'm just curious. I think one thing t…
Yes, I used LLMs to develop this. I think the README has more emojis than any mortal could summon. Hehe
I used ChatGPT to design the solution that I wanted and Claude Sonnet to do most of the coding.
I'm trying to figure out what works for me in the brave new world of AI enabled development, so that I can make recommendations to my team.
A few things that really helped me here were:
- Having the gitlab cli (glab) installed and configured was very helpful because it allowed me to do things like lint the CI file and inspect the build output in the LLM context.
- Having the zereight/gitlab-mcp installed was useful as well. Even though I can make Issues and MRs using the CLI, the LLM frequently made escaping mistakes when writing long comment sections. The mcp tool was great for this.
- Almost all of my process started with me describing a bug or feature, then asking the LLM to investigate the feature and create an Issue. From there I tried as much as possible to keep the scope of my work small and exclusively tied to an issue branch.
I'm a reasonably good programmer - I've been at it for 30 years. I think there's no question that LLMs expand my "radius of capability." Just like everyone else, I'm trying to figure out the best way to safely maximize this new world of tools.
Re: Show HN: Sping – An HTTP/TCP latency tool that's easy on the eye
#20> It's easy to install if you have pip. (Available at service-ping-sping on PyPi) Consider rewriting the program in Go, then you’ll have a statically linked binary that’s much easier to install (less dependencies) and will be much faster too.
You're certainly right that statically linked binary is the most optimal expression of this goal. Especially for use in a secure environment.
Alas, this is just a python tool :)