Yes, it is used, but of course it is not all-inclusive to handle all hardware types out there in the world. That takes actual real-world usage to exercise that, although kernelci is starting to pick up the slack in that area.
I've written a dozen internal dashboards where something like this would have been useful. Rather than writing server side code to craft queries and return results, you can add arbitrary queries easily to the front end. Just use a read-only DB account and you are golden.
Is it the right way to do it? No.
Is it something you can stand up in a few hours so you can work on the things that keep your startup afloat instead? Absolutely.
This sort of tool would be nice for PoC - but if you're using it for production anything and have any customer information (or really, any information of value) saved in that database... it would be terrible - even off an R/O connection.
Just a little clarification: the architecture is 3-tier, databases are not directly exposed; the software includes an authentication layer and firewalling rules: you have fine granularity on tables & columns access per user.
I suspect this would violate a bunch of privacy protection laws if done poorly. At least in my country "processing" private data also includes querying against it.
Seems like if you already have a shell it'd be easiest to just dump data directly over a pipe.
I guess SQL over HTTP could be used to directly operate on databases from resource constrained devices that don't support the full socket library for whatever database you're using?
>I guess SQL over HTTP could be used to directly operate on databases from resource constrained devices that don't support the full socket library for whatever database you're using?
Indeed. I think botnets could be an example of such "devices."
Some use cases & examples: 1) Allowing mobile App code to access directly remote data without programming intermediary Web services. 2) Python data scientists can crunch any SQL databases in their organization using standard PEP 249 API calls, even if the SQL engine is far away. 3) Data publishers can expose more easily and quickly their data, without having to export tables in tar.gz / zip files for download and create dedicated and documentated web pages for that.
Kind of offtopic: I did some Ruby and I find some of the conventions really confusing; for example, the lack of “()” when calling a method. You never know if you’re accessing a property of calling a method until you grep the code. Am I the only one who feels this?
I used to find this odd as well, but that feeling came from a misunderstanding of what a "property" is. When you use `attr_reader :foo` what you're actually doing is calling a method that defines a method on the class for accessing `foo`. `a.foo` is not accessing a property, it's calling a method. `a.foo = 2` is not writing to a property, it's calling a method called `foo=`. The "()" can be left out because it's never ambiguous whether you're calling a method, because you're always calling a method.
I remember loving this when I learned Ruby. There's a certain elegance to it.
However, I'd say for practical purposes, it still leaves me with the problem that in my day to day coding I'm left with the same ambiguity. I don't know if I'm calling a simple-assignment auto-generated method that is setting a property, or a method that does all sorts of stuff under the hood.
While I'm still fond of Ruby, I've come to prefer less ambiguity. I like to be able to see at the calling site whether what I'm doing is calling a method or setting a property, and parentheses are a great way to signal that.
As an aside, one thing I didn't like about Elixir was that it also made parentheses optional. Once I realized why this was necessary, and once the formatter was added and enforced parentheses as a default, it stopped being a problem. Still, every language I've used where they're optional have caused weird little problems that never seemed to be outweighed by the convenience (CoffeeScript comes to mind).
But all that said, it's not too high on my list of things to hate on :).
> I like to be able to see at the calling site whether what I'm doing is calling a method or setting a property
In Ruby, as is also true in many languages that have a syntactic distinction, setting a property is always ultimately calling a method, so the distinction is illusory. What you may want is a purity guarantee (well, that getters are pure and than setters have no effects except on the state specifically backing the property, but the latter gets complicated to apply to nontrivial properties), but most languages that let you distinguish whether properties or methods are exposed in an API don't provide a that kind of guarantee with properties, either, just more boilerplate code to implement them.
And the whole point of properties over exposed data members is to abstract behavior so that implementation changes don't change APIs.
Even when it's not enforced by the language, it can be something enforced as part of the coding style by the team - that Foo vs GetFoo() indicates presence of side effects, or potentially expensive computation.
> As an aside, one thing I didn't like about Elixir was that it also made parentheses optional.
Ocaml does something similar. If you have nested function calls in a line of code, the interior calls look just like lisp. But the outermost one omits the parentheses.
It's always a method in Ruby because you can only access @properties in method implementations.
What you're describing holds in e.g. Scala, where it's by design: they feel it should be an easy-to-change implementation detail whether a name is backed by a direct field access or a method. IMO that's a reasonable stance in a functional(ish) world.
“Properties”, in most languages that have them, are an way to make method access look like access to data members (no parens, getters just use the name, setters use name + = with the new value on the right of the = instead of in parameter position.)
Ruby doesn't have properties except as an alias for a certain pattern of methods, and in languages that do have properties they are almost invariably just a layer over calling getter and setter methods.
You seem to confusing “properties” with “data members” which, it is true, Ruby does not permit external access to except via method calls. But properties are a way of calling methods with a syntax that looks like direct member access, not actual direct member access.
You can never access a property in Ruby from outside the object, you are always calling a method. Calling "attr :foo" just defines two methods, "foo" and "foo=" which then can be used to access the property.
I think this is a rather elegant solution to properties, that you always need to expose them with getters and setters and that properties and methods do not share the same namespace.
No, I'm still struggling with that too. It's probably the main thing that still grates in Ruby syntax for me (along with `unless` and implicit returns). I'm sure it'll become natural as I use the language more, though!
Learn more languages, you might like lisp or maybe lua with optional parentheses or maybe even haskell. Don't let small things discourage you from the bigger picture
Indeed. This lax syntax has led to the proliferation of so-called DSLs which are really just Ruby with a few functions pre-loaded. Personally I’d rather they just admit what they are rather than trying to pretend they’re some special thing. In Python it would just be a package that you import * and there’s no shame in that.
All this is based on a survey. It would be very interesting to know the number of people that participated in that survey and the tech they’re working on.
I'd also like to hear what part of "Azure" they're using. Microsoft was smart to leverage (force) O365 customers into being Azure customers using AzureAD. What I'd like to know is how many have actually graduated beyond that and are hosting real infrastructure.
As a central European I would also like to know who hosts anything on Azure. They are building new data centers here I believe, but the connection speed their services are providing is laughable. It may work for a retro-site from the 90s to simulate a 56k modem.
If you restrict your employees to browser based office, you would loose a vast amount of productivity.
Their success is probably based on Office alone. AWS does supply extremely fast services and we use it for hosting. But business owners often prefer to use services from a single provider, so MS does indeed have an advantage.
Yes, the numbers don't seem to match other reports I've seen on cloud market share. Maybe they surveyed people with MSDN subscriptions or companies that already have services in Azure. Additionally, my understanding is that Microsoft reports other "cloud-related" services (Office365, etc.) as part of Azure. If that's true then they are nowhere near AWS levels.
This report also states that Google may be looking to purchase their way to the top of the cloud offering pile. I'm not sure who they would get that would make that much difference; Rackspace?
First of all, it really shouldn't take any brain cycles to figure out that problems were caused by an 'automated upgrade from PHP 5.6 to PHP 7.2' (who does that anyways, and why?).
Second, it's almost 2020. Why there still isn't a better way to debug PHP than using die()?
And third, "mysqli" has been the defacto method for SQLing, while "mysql"was deprecated years ago.
What do you mean "there still isn't a better way"?! There are plenty debugging tools, many with integrated support in most IDEs. But, honestly, the only time I needed them was to figure out the place for performance optimization, var_dump() + die() are really perfect to debug anything. In fact, I feel that the nature of PHP being "fresh start on every call" + no compilation needed makes it probably the easiest to debug language out there I know.
I don't really understand what are they fixing here. They point that current web development has shifted to "REST backend" and "SPA frontend", which (according to them) is not a good thing (why?). Their solution is to make you write (again) a "full" MVC-backend that also serves the UI (frontend), and additionally, extend it with another frontend layer (Vue).
IMHO that is not fixing the initial problem they are stating that exists, but making it worse, because now you have to write UI-related code in two languages (ruby and js) instead of the 1 that is currently needed (REST + SPA).
If I'm not wrong you're assuming that the REST backend is written in JavaScript. This is not always the case. I personally saw that happen only once. All the other times the backend was either Java, Ruby, Python, Elixir.
What's risky is that a few people will know this technology. Far more know React, Angular, Vue. On the other side the same person writing the backend can write the frontend, assuming knowledge of HTML and CSS. So one project, not two. Probably cheaper.
