It's not exactly the same thing but it achieves the same goal and is opensource.
API services are generated from RAML files (yaml) No code required for simple crud, biz logic can be hooked using http event handlers. Uses Elasticsearch for reads and Mongodb or Postgres for writes. Other DB can be hooked by writing the proper Db engines, it's all documented.
I don't know the details of that particular case but in France, a lot of laws have penalty clauses in them which doesn't leave much at the discretion of the judge. It's a different judicial system.
You write your own handler and use the combination of the `operationId` field and an additional `x-handler` field to location your function.
You can think of it like this:
`pathHandler = require('${project-root}/handlers/${x-handler}').${operationId}`
The server provides dependency injection so that when you implement your handler-level function it can access several re-usable services to do the "real work".
Generally my handlers are limited to getting the parameters off the request, passing them on to a (chain of) service(s) and getting the response back out to the client.
How much does Ramses integrate with the data source "automatically"?
Is it like StrongLoop/LoopBack?
We've found that for most of our projects we're not connecting directly to a database, but instead trying to present an (mobile or web) app-specific API that abstracts/unifies/focusses the many data sources and services that may be needed.
For example, one recent project involved data coming from some old SOAP services, new HTTP (but not exactly RESTful) endpoints, and several public APIs too.
Hm, why is opencv not there? I was playing around with it last week, and it seems it works well for only py2 right now (from what I could gather). OpenCV should be there in that list, a lot of people really need it.
You have grossly misunderstood. That "Hahahaha" is directed at Guido (creator of python and self-declared benevolent dictator for life) and his short-sighted arrogant decision to break backward compatibility moving from Python 2 to 3. He recognized it as a mistake but out of some stubborn pride resolved not to fix it. Ever. So damn skippy my response to him is "Hahahahaha". The programmers that have put up with his poor decision making obviously deserve respect. I am sad that you assumed it was directed at the programmers having to deal with Guido.
Fortunately there is a simple solution -- fork Python 2.7 to make the Python 2.8 that Guido refuses to make. A python version that doesn't have compatibility issues with Guido's playground programming. This version would not have the poor performance of Python 3. This version is essentially already made with PyPy. I just wish everyone would have told Guido to get lost 7 years ago and switched to a development group with sane deprecation of features. If we had then all of the programmer effort that was poured into making their code Guido approved would have been saved. Can you imagine how much better Python development would have been without a 7 year lag that included BREAKING the code base of everyone who had previously programmed in Python 2.x?
Guido is the self proclaimed benevolent dictator for life. However, that doesn't describe a leader who breaks the programming efforts of every developer using the language prior to Py3k. He then has the stubborn arrogance to deny a transition version and instead requires 7 years of programming effort. He certainly deserves a "Hahahahaha" that it took 7 years to get "almost there". At least he is not still shocked that py3k wasn't greeted with open arms. Hopefully before 2020 he will swallow his pride and agree to a transition version -- a 4.0 which works with 2.7 or a 2.8 that works with 3.x. If not, a fork will happen.
Hopefully that clarifies the previous comment, and congratulations to the Scrapy developers for powering through and putting up with a language that was purposely broken by the language developers.
"simple solution" - simple to propose, certainly. Many have conjectured about a third-party (non-core developers) who might take on a 2.8. Any takers? No.
"self proclaimed benevolent dictator for life" - As a bit of minutia, it was Ken Manheimer who proclaimed him thus. This is a minor point, of course.
"a 4.0 which works with 2.7 or a 2.8 that works with 3.x. If not, a fork will happen." - I look forward to a solution to enable chained exceptions and asyncio to work under a 2.x environment with a __future__ flag. I wonder who will pay for the hard work.
I agree he's not being a great sport, but I sort of see where he's coming from. Having worked with python in the last few months for computer vision problems, I've been really frustrated with how things are. I was expecting better. At this point I don't use python for my work anymore, I use matlab. It's superbly well-documented, and things just /work/. And of course, nothing like the mess you see with this py2/py3 problem is to be seen anywhere near matlab. Yes, it's not free, but I've decided that the amount of time I had to spend, the headaches I had to endure, they were not worth the free price of python (and matlab for its great support was in fact worth its price). ymmv.
This is mostly true until you need new data that is not a .mat or image, or to deploy to a server for production (licensing Matlab for multi-core servers is pretty rough), or deal with strings, or send stuff over the network, or one of the other thousand things the Python ecosystem does better. For algorithmic experiments, Matlab has an edge but the "with batteries" / overall utility approach has always been the primary strength of Python for science.
In my experience Matlab compatibility problems are much more common, because many Matlab users don’t update to the latest version (this costs money), and changes to common packages which work on the latest version tend to break on older Matlab versions. This is exacerbated by a lot of research prototype quality code in the Matlab ecosystem; grad students don’t necessarily have the bandwidth to worry about regression tests or compatibility workarounds.
More generally: (a) Most Matlab packages have much messier APIs than the equivalent python packages, and anything complicated written in “object oriented Matlab” tends to have much weirder failure modes in edge cases than Python, because the basic data types and control flow mechanisms are much less robust and much less capable than Python/Ruby/Lua/Javascript/Lisp/etc. equivalents. (b) Python has much broader library support for doing anything that isn’t pure number crunching, which makes it a much more flexible tool overall.
If you can do your work sticking to only the packages directly provided by Mathworks, and you are comparing those to third-party Python libraries for equivalent functionality, then you might be right though.
Py2/3 shouldn't impact CV code at all. THe major issue should be installation, which is generally a solved problem. OpenCV, and the scipy stack fully support python3, and are some of the best documented libraries I've ever encountered (better than the bit of matlab I've used for robotics at least)
I want to like Python 3 but the print statement change really kills it for me. Years later it's still frustrating on the occasions I write a python script. If I ran a project like one of those, I might not use Python just for this reason.
Really?, Really! Because every other output method was a function the statement is annoying as all hell.
Swapping between print and fh.write() log.error(), stringio.write(), sys.stderr.write(), mycustom_thing_that_suppresses_print_when_quiet_arg_supplied() in python 2.x is annoying as all fuck and simple 'ct(' with python 3.x
I really don't see how the print statement can be that bigger deal. After a week at most you're used to it and `print(x)` is valid syntax on Python 2 (so don't worry about what way to write it).
I write Python 2 code, and just always use `print("...")` in both. It makes a lot more sense, matches other languages syntax, and is compatible in both. I honestly don't see it in any way worse than `print "...."`.
Been using most of __future__ for years to make the transition seamless for me. This is what Py 2.x devs should be doing now. It's not like the path forward hasn't been paved for us for many years.
I empathize. Makes me want a parenthesis-optional language, though that has its own headaches.
I find switching to log() as an output function helps psychologically - it's shorter to type than print, and it's something I'm more likely to keep in production.
It's not exactly the same thing but it achieves the same goal and is opensource.
API services are generated from RAML files (yaml) No code required for simple crud, biz logic can be hooked using http event handlers. Uses Elasticsearch for reads and Mongodb or Postgres for writes. Other DB can be hooked by writing the proper Db engines, it's all documented.