Improving Wetware

Because technology is never the issue

Hurl as an alternative to Postman

Posted by Pete McBreen 05 Oct 2021 at 19:50

Hurl is a Rust wrapper around libcurl that provides an easier to use interface to Curl. Not a replacement for Playwright, but for testing a JSON REST endpoint or validating the server side of HTML web pages it looks to have a place in the toolkit.

It is controlled either from stdin or files with a nice syntax

GET https://improvingwetware.com/
# confirm response code 
HTTP/1.1 200
[Asserts]
xpath "//div[@class='post']" count == 20 # confirm 20 posts per page
[Captures]
nextPage: xpath "string(//span[@class='next']/a/@href)" # get href to the next page

GET https://improvingwetware.com{{nextPage}} # use captured href to navigate to that page

HTTP/1.1 200 # and make sure we found that page
[Asserts]
xpath "//div[@class='post']" count == 20 

Only gotcha is that you might need to have an XPath Cheatsheet link handy if you have not needed XPath much for navigation around a web page (I mainly use CSS selectors for Selenium and Playwright)

>hurl test.hurl  --test
test.hurl: running [1/1]
test.hurl: success

executed: 1
success: 1 (100.0%)
failed: 0 (0.0%)
execution time: 1156ms

Note. If you are running under windows command prompt, you cannot use the normal wildcard to specify multiple files, as it assumes that the wildcard will be expanded by the OS. Fix is to run under WSL

>hurl *.hurl  --test
error: The filename, directory name, or volume label syntax is incorrect. (os error 123)

Under WSL there are no issues as it expands the wildcards automatically

$ ./hurl.exe *.hurl --test
t2.hurl: running [1/2]
t2.hurl: success
test.hurl: running [2/2]
test.hurl: success

executed: 2
success: 2 (100.0%)
failed: 0 (0.0%)
execution time: 2132ms

Craftsmanship and Engineering

Posted by Pete McBreen 01 Oct 2021 at 17:23

Found a recent reference to my book by Hillel Wayne in a blog post where he interviewed engineers who moved into software development to get their take on the “is software development engineering” question. Overall his take is that

there’s a much smaller gap between “software development” and “software engineering” than there is between “electrician” and “electrical engineer”, or between “trade” and “engineering” in all other fields. Most people can go between “software craft” and “software engineering” without significant retraining. We are separated from engineering by circumstance, not by essence, and we can choose to bridge that gap at will.

I have to agree with Hillel that despite having a masters degree in Manufacturing Systems Engineering I am not a traditional engineer.

I believe everything McBreen said about software is fairly reasonable, about how hard it is to predict things and how it’s intensely personally created. What he gets wrong is the assumption that engineering is not this way. Engineering is much richer, more creative, and more artistic than he thought. But of course he would have an imperfect view: he is, after all, not a traditional engineer. Are we really engineers