41–50 of 83 posts
Interesting idea. The proliferation of convention-dictated top-level URLs offends the design sense of many web architects. Possible alternatives are to: • shoehorn a pointer to a varying URL inside an existing convention-dictated place – as for example with sitemap pointers inside robots.txt files. • let the resource live anywhere but specify its location to consuming services via some out-of-band mechanism. That is,…
Really love the idea of text file based monitoring, hate the cucumber interface. I stomach it in rails but I'm not a big fan of English in my code
I'm curious about this -- don't you use APIs which use largely, if not universally, English identifiers? Or is there a version of, say, the .NET Framework where the API itself is written in French, German, or Spanish? Or what language has a custom parser for each language so that you can write keywords ("if", "for", " do ") in your native language?
result = object.doSomething(someString.toUpper(), someInt);
with the instance named object, call the doSomething method
passing as parameters the result of calling the toUpper
method on someString and someInt storing the method return
value in the result variableSo how many of you like the cucumber/gherkin format over anything else mentioned? Would be helpful to know to gauge interest.
I like the idea, but not the URL. How about moving it to "/.well-known/monitors.txt" in conformance with RFC 5785?
Especially if you want lots of providers to support it, pick something super easy to parse.. JSON is the obvious choice there:
[{ method: "GET",
url: "index.html",
tests: [ contains: "nyaruka",
response_in_ms: 500,
status: 200 ] },
{ method: "POST",
url: "login.html",
params: { foo: "bar" }
tests: [ "status": 200 ] }]* Exposing a "monitors.txt" is a potential security hole that reveals more about your infrastructure than you meant to.
* Restricting monitors.txt to a given service (by htaccess IP restriction?) is brittle and gets you out of "write feature"-land and into "do sysadmin"-land, which you're trying to avoid anyhow.
* Cucumber is an unnecessary extra layer that doesn't do much besides just frustrate the user who has to write just the right English syntax to get what he wants. See also: Monit config definitions. The files read nicely once you get them configured, but it can be a downright bear to find out what just the right magic combination of keywords and phrases is to get it to do what you want.
* If you want client-side managed monitoring, why not have some interface to your chosen monitoring service that you invoke via your Cap deploy? That's something that you can make reality today, rather than waiting on service providers to implement it.
The concept of being able to define your monitoring as a part of your application and then just deploying it with the rest of the package is really appealing, but you still have to go tell monitoring services where to find your monitoring file, you still have to wait on monitoring services to implement support for it, and monitoring just isn't that difficult of a problem. How often do you change your monitoring rules?
The problem is when people think "Hey, I have a computer science problem. I know, I'll express that problem in English!" and now they have two problems