jicea

> Users need open source projects, but open source projects do not need users.

I get what’s the author is trying to say, but, as a maintainer of a small, free, open source project [1], I’m really happy to get more users:

- having more users helps to keep motivation

- it helps also with the credibility: we work in a large telco, and popularity can justify us working on it on our work hours

- we get more feedbacks, more bug reports and so we improve our tools. As we use it intensively, it’s benefit for us

When your project reach a certain level of popularity, maybe you don’t « need users » any more but I think the majority of GitHub projets are small, relatively obscure, and can benefit from feedbacks, usage etc…

[1] https://github.com/Orange-OpenSource/hurl

I googled a video of the « walking » moai, very impressive: https://youtu.be/yvvES47OdmY

I suggest you could try Hurl (https://hurl.dev). It’s a cli tool to send and test HTTP requests, in plain text. As I’m one of the maintainer, I find it quite readable…

I’ve seen an animation a few days ago [1] about the market share evolution of smartphone constructors for 20 years. The animated pie beautifully tells the raise of Apple, Samsung, Huawey and the fall of Nokia, RIM and others. So, fully agree, pie charts can be used if you don’t need the precision.

[1] https://www.linkedin.com/posts/jameseagle_mobilephones-datav...

Hi, one of the maintainer of Hurl [1]. It is effectively basically just curl (we're using libcurl under the hood). I would say that we have added the ability to chain request (you could use curl in a shell script), and a bunch of assert (like jsonpath, xpath etc...) on response (which you could arguably do also with shell script).

We also wanted something text based, that could easily be integrated in a CI [2] for instance. We are using Hurl to test our web application (~2M unique visitors/month). Very happy with it currently, but there are really a lot of very good tools in this space (as we can see in these comments).

[1] https://hurl.dev

[2] https://hurl.dev/docs/tutorial/ci-cd-integration.html

Could you attach a proxy (mitmproxy [1] for instance) and check the differences between HN requests with/without Private Mode ?

[1] https://mitmproxy.org/

I’ve to build a cli HTTP client in Java and went with OkHttp [1], as it was widely used on Android. I’ve to add support for GET requests with a body but I wasn’t able to do it with OkHttp. The library was rather opinionated and you couldn’t add a body to a request body back then [2]. I was rather surprised, because I thought HTTP specs allowed it, while discouraging; so an HTTP library should allow this kind of usage. I went back to Apache HTTPComponents, while less fancy than OkHttp but also less opinionated, and was able to complete my client. Things may have changed, it was a few years ago.

[1] https://github.com/square/okhttp

[2] https://github.com/square/okhttp/issues/5803

[3] https://hc.apache.org/

Fixed, thanks!

Shameless plug, we've built hurl [1] to add some syntactic sugar over curl, with plain text. For example, you can write a text file post.hurl:

    POST https://api.ctl.io/v2/authentication/login
    {
      "username": "YOUR.USERNAME",
      "password": "YOUR.PASSWORD"
    }

and it will send the same POST request with a json body:

   hurl post.hurl

You can add asserts on the response too:

    POST https://api.ctl.io/v2/authentication/login
    {
      "username": "YOUR.USERNAME",
      "password": "YOUR.PASSWORD"
    }
    HTTP/1.0 200
    [Asserts]
    jsonpath "$.status" == "LOGGED"

Under the hood, we use libcurl and a Rust binding. The HTTP engine is curl because curl is awesome!

[1] https://github.com/Orange-OpenSource/hurl

Could you share your Spring/Spring Boot alternatives? Are they Java based? I'm doing backend stuff with Spring Boot and I would like to test alternatives. Spring boot is not that difficult to work with, but I would like to test a "simpler" solution.

Agree, collapsing margins are counterintuitive, and only applied to top and bottom margin. It’s really surprising how many people don’t know it’s a thing and fight the box model. If you think you’re constantly fighting layout, try to read the MDN docs [1] with a fresh eye. I was guilty to think I needn’t learn CSS, and reading the MDN really help me.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS

A few years ago, I implemented UI automatic tests on a bunch of iOS apps. The Apple go-to framework was UIAutomation. It was a pretty good tool for this job, albeit limited.

What I liked a lot was that the framework relied upon accessibility. To automate the testing of an app, you firstly had to make sure that the app was really accessible and then you could built upon accessibility attributes to add automatic testing.

I found it very smart because developers were incentivized to make their app accessible. Accessibility was, in a way, a tool to describe semantically a UI, so a screen reader, a test framework, the OS could understand how the UI was structured and acted upon.

One of my (really) old post about UIAutomation: http://blog.manbolo.com/2012/04/08/ios-automated-tests-with-...

It immediately reminds me of Voyelles a poem, written in 1895 by Arthur Rimbaud

  A noir, E blanc, I rouge, U vert, O bleu : voyelles,
  Je dirai quelque jour vos naissances latentes :
  A, noir corset velu des mouches éclatantes
  Qui bombinent autour des puanteurs cruelles,
    
  Golfes d’ombre ; E, candeurs des vapeurs et des tentes,
  Lances des glaciers fiers, rois blancs, frissons d’ombelles ;
  I, pourpres, sang craché, rire des lèvres belles
  Dans la colère ou les ivresses pénitentes ;
  
  U, cycles, vibrements divins des mers virides,
  Paix des pâtis semés d’animaux, paix des rides
  Que l’alchimie imprime aux grands fronts studieux ;
  
  O, suprême Clairon plein des strideurs étranges,
  Silences traversés des Mondes et des Anges :
  — O l’Oméga, rayon violet de Ses Yeux !

Arthur Rimbaud, Poésies

But you’re right, it also looks like an alien alphabet. Very cool

Following a style guideline is really important in scripts. But, having your scripts checked by ShellCheck [1] is really mandatory. Can’t imagine to write any script without it.

[1] https://www.shellcheck.net/

Hi, HN seems to remove the anchor from the submitted link, direct link to the doc is https://docs.github.com/en/github/writing-on-github/getting-...

I'm a maintainer of a cli HTTP client with a text plain file format, Hurl [1]. I would like to begin to add support for various IDE (VSCode, IntelliJ), starting from syntax highlighting, but I have hard time to start.

I struggle on many "little" details, for instance: syntax error should be exactly the same in the terminal and in the IDE. Should I reimplement exactly the same parsing or should I reuse some of the cli tools parser? If I reuse it, how do I implement things given than, for instance, IntelliJ plugin are written in Java/Kotlin, while VScode plugin are Javascript/TypeScript, and Hurl is written in Rust...

Very hard to figure all when it's not your core domain,

[1] https://hurl.dev

As a matter of fact, our first implementation of Hurl was written in Python. We switch to Rust because:

- we're a 30 developper team with Linux, Windows and macOs computers. Installing Hurl with Python on Windows boxes was always a challenge and the single drop Rust binary has been a relief for us,

- in a CI, we really want to run tests as fast as possible. The Rust version (the actual one) seems a lot faster that our Python prototype (certainly due to our lack of optimisation in our Python code)

Yes, we began to work on Hurl three years ago and the file format was "accidentaly" close to IntelliJ's HTTP file format. For the request part, it's not a coincidence since Hurl and IntelliJ's HTTP looks like "bare" HTTP format. They differ drastically on the response tests.

We keep working on Hurl because our main goal is to be able to easily run integration tests on a CI or locally in a terminal, which can be difficult with IntelliJ.

But yes, this shows that is really a need for such a tool.

For reference, IntelliJ format:

  GET https://httpbin.org/status/200
  
  > {%
  client.test("Request executed successfully", function() {
    client.assert(response.status === 200, "Response status is not 200");
  });
  %}

  ### Failed test: check response status is 200
  GET https://httpbin.org/status/404
  
  > {%
  client.test("Request executed successfully", function() {
    client.assert(response.status === 200, "Response status is not 200");
  });
  %}

We're releasing a new version of Hurl, a simple HTTP cli tool built on top of libcurl and Rust.

Hurl allows running HTTP requests defined in a plain text format. It can be used to fetch data, or play a scenario (sequence of requests), asserting responses along the way. With its textual format, it is aimed for both devops and developers. With its command-line usage/simple unique binary, it is aimed for both local dev and continuous integration.

An Hurl sample:

  GET https//example.org/books
  
  HTTP/1.1 200
  [Asserts]
  jsonpath "$.validated" == true
  jsonpath "$.books" count == 12
  jsonpath "$.books[2].name" == "Dune"

Since our first "Show HN" submission [1], we have made the following changes:

- full native support on Windows

- improve Hurl file format syntax (with md5, sha1, sha256 asserts for instance)

- add a tutorial on how to use Hurl [2]

- add a simple interactive mode

- a lot of bug fixes!

In our roadmap, we want to have a better support for package manager (brew, apt etc...), better error feedbacks.

We're looking for contributions on improving/correcting our documentation, build an UI client above Hurl, better IDE tooling integration.

And last but not least, we would be happy to have feeback on it!

[1] https://news.ycombinator.com/item?id=25655737

[2] https://hurl.dev/docs/tutorial/your-first-hurl-file.html

I’ve a very small working experience with Go, tried it on few personal projects to test the language. Globally I really like it, and I’ve been pleased by a lot of « features » (simplicity, explicitness, readability of the standard lib etc…).

One thing that I miss was an immutability story. You have values/references and, again I’m a beginner, I’ve the impression that passing references are favored. Wouldn’t it be nice if the compiler was able to check if you can mutate a reference or not? There are some proposals [1] that are discussed [2], that can be a nice evolution.

[1] https://github.com/romshark/Go-1-2-Proposal---Immutability

[2] https://github.com/golang/go/issues/27975

Testing apis with Postman is really interesting and you can learn a lot just by inspecting requests with the browser’s developper tools. We’ve build a command line tool [1] to be able to simply add integration tests in our CI/CD pipeline for our website (that was difficult with just Postman or Selenium)

[1]: https://hurl.dev

Very nice and works perfectly on macOS/Safari 14! It's refreshing to see that there are only two direct dependencies. From package.json

  "dependencies": {
    "js-beautify": "^1.13.13",
    "uglify-es": "^3.3.10"
  }

Yes, our stack is Spring Boot + Kotlin on the back side, TypeScript + Vuejs on the front. We’ve millions of unique visitors each month, and we’re pretty satisfied with the stack.

Developing now 80% in Kotlin and 20% in Java (on backend), I really think the main advantage of Kotlin over Java is nullability. You can use @Nullable/@NotNull annotations in Java, but nullability being a part of the type system in Kotlin is better. I also love being able to create simple functions and add extension methods to existing classes. But still, nullability is the strongest advantage of Kotlin and I don’t see how Java will address it.

Very nice work, seems really fast! Since it’s written in Rust, do you plan to release a Windows version ?

HTTPie requires Python so Ht could have another advantage being easier to install.

We are also developing an HTTP client in Rust using curl (it’s an overwhelmed place!), it’s still very young but I link here anyway https://hurl.dev

[edited] there is already a Windows version, so really good job!

> The release page contains prebuilt binaries for Linux, macOS and Windows.

I’ve found that Kotlin has changed that, at least for me. I enjoy playing with it even for small projects, something I’ve really never done with Java.

> Many hours of searching for how Gradle detects changes were fruitless, because it doesn't even try, really. Gradle basically always runs everything, which is why it's so goddamn slow. This is because the entire dependency graph is constructed dynamically on every run,

Something that is not clear from the Gradle documentation is that every task must have its input and output defined (inputFile, inputDirectory, outputFile, outputDitectory property). It is absolutely essential so Gradle can infer which task has to be rerun when, for instance, a build is run. This is usually done for the ‘basic’ task (like build, test etc..) but you have to specify it when you have custom task. This can really make a difference in speed. Another trick is to use the console option (gradle build —console plain) so you will see each task that have been run and their status (if they have be runned, or if they have been skipped due to dependencies)

No, it’s really the output of:

  man hurl

:) But as English is not our primary language, there must be a lot of typo/bad English

Yes interactive mode is a must have.

For the sample, maybe this is not obvious but you have to write the sample in a text file:

$ vi test.hurl

  GET https://news.ycombinator.com
  HTTP/1.1 200

And then use this file with Hurl:

$ hurl test.hurl

Thanks for the feedbacks!

Looking at repost, I can see that there is definitely a place for an HTTP runner/tools that can do asserts on response.

For your suggestions, environnement variable support is certainly a good feature (actually, we can inject variable in the command line ex: hurl --variable user=dude file.hurl). Including another file is also a good suggestion. Currently we write tests by hand or sometimes generate the Hurl text file when we want to reuse steps, but a build-in support is a good idea.