OSRM have realesed new version, v5.
And I can't find anywhere, what's new in it?
I found new documentation of HTTP API, https://github.com/Project-OSRM/osrm-backend/blob/master/docs/http.md , but it isn't enought.
I don't know, whether it makes sense to update version. I use OSRM only for finding hiking trails on the single city.
I suggest you look at OSRM's changelog.
5.0 brings drastic change to the HTTP API, but also lots of improvements to how instructions are generated, as well as a lot of bug fixes and other tweaks. If you're planning on continuing to use OSRM, I would recommend upgrading.
Related
I need to develop REST server strictly accrding to jsonapi.org specification and I'm not sure if there is some complex solution or even if it's easy to develop such thing.
I've found sails-hook-jsonapi, but it looks unmaintained for some time.
I'm new to Sails and not aware of all it's features and would appreciate any help, I may missed something obvious.
I have needed this too. There is not anything that works yet with Sails. sails-hook-jsonapi does not work correctly. I Forked that code and am maintaining my own version of it but there are still significant attribute serialization issues with multiple records. However, it does work at a basic level. I am also working on a new project sails-generate-jsonapi-blueprints but it is not nearly ready yet.
Sails is great but can ba a royal PIA. The guys maintaining Sails have had many requests for jsoanapi.org support but I do not believe that will happen anytime in the near future. If you REALLY must have JSONapi.org format I would suggest Loopback or some other API that already has support for it out of the box.
Actually, I take part of that back. sails-hook-jsonapi is working. I made a little change in the fork I maintain. https://github.com/NikkiDreams/sails-hook-jsonapi. Ian is maintaining the original project fork too I believe. https://github.com/IanVS/sails-hook-jsonapi
So the catch about the hook is that it hijacks every single request sent to responses/ok.js If you need something like an Authorizer that does not need jsonapi create a variant of ok.js that simply does a res.json(data) without the jsonapi-serializer being called when serializing the response.
sails-hook-jsonapi will serialize most of your data to your needs. But it still has a few limitations. Depending on the complexity of your queries these may not be an issue.
TODOs: Included request parameter handling (400 response if present)
Links
Top-level "self" links
Top-level "related" links
Resource-level "self" links
Related resource relationship links
Metadata links
Pagination
Formatting
Non-dasherized attributes
Sparse fieldsets
Long story short - there is no way to do it out of the box with little time investment. At least for now.
But sails-hook-jsonapi looks like good starting point, repository seems to be active now.
I've done project prototype on loopback.io framework, because I was in hurry and loopback had better jsonapi support.
Several days ago, Mirth Connect version 3.3.0 was released. Noting the great new features, we decided to upgrade immediately (just days after the initial release). We followed these Upgrade Guide instructions during the upgrade. However, the specifics of upgrading from 3.2 to 3.3 are missing from these Upgrade Guide, so we did not suspect much to change on the way Mirth should be implemented...
During this process, we ran into a handful of issues that caused our production channels to go down for several hours (†).
It would have been really nice to have specific information for this upgrade. Some issues that would have been really useful to know beforehand (just examples, no need to actually answer):
Are you changing the default toString() method for objects/arrays to return JSON representations?
Does this upgrade include a db migration, meaning we can't revert to
previous version once upgraded?
Because code templates are now children of "libraries", will we need to access the code template through the library, or will we be able to call it directly (as it was in 3.2)?
A solid documentation like this would have allowed us to understand the full gravity of what needs to be accounted for when upgrading. Typically, Mirth has some documentation for each minor release. But even then, the documentation is very terse. Would it be possible for the Mirth team to start being very explicit with what the upgrade entails?
The Rails Upgrade Guide (obviously much larger team, so can spend more bandwidth on this spec) provides a really great example of what an upgrade guide should entail.
† yes, yes, I learned my lesson, I won't upgrade immediately to production anymore
The Release Notes page will give the lowest level of changes to the application, but you're right in that a better documentation is needed.
The documentation here and here seems to be saying that I can only filter strings with exact matches "Supported Operators for Strings :EQUALS:"
I'm using the IPP .NET Devkit so my search looks like this:
CustomerQuery qboCustomerQuery = new CustomerQuery();
qboCustomerQuery.Name = "Southwest";
List<Customer> customers = qboCustomerQuery.ExecuteQuery<Customer>(context).ToList<Customer>();
However I need to find a customer name that contains "Southwest" in it. Is my only choice really to cache the customer names locally and search my own db? This seems asinine. Please tell me I'm being an idiot and that this system isn't really this obviously broken.
Unfortunately, the Intuit Anywhere APIs really are this crappy at the moment. :-(
Here is the list of filter operations that are supported for strings:
https://ipp.developer.intuit.com/0010_Intuit_Partner_Platform/0050_Data_Services/0400_QuickBooks_Online/0100_Calling_Data_Services/0030_Retrieving_Objects#Supported_Filter_Operators
Note that the only one supported is:
:EQUALS:
Ick!
Fortunately, Intuit is hard at work on the v3 APIs. It was rumored that v3 will support better filtering.
Unfortunately, Intuit is doing their usual thing and not involving developers in the v3 dev process anymore, so we really won't know whether or not v3 is going to suck until it's actually released. sigh You'll notice the last update about v3 data services was in October by Wei... unfortunately Wei isn't even on that team at Intuit anymore, so who knows what the status is, or even if there's anyone at all working on v3 anymore at Intuit.
I had to do something similar. Sadly, as Keith pointed out, it is not yet supported. What I ended up doing with this was fall back on LINQ.
I read in all of the customers, and then filtered using LINQ. This prevented me from having to write and read from a db and speed things up by keeping the data in memory.
So, for now, try LINQ. Hopefully we will get a better solution when v3 comes out.
For a new J2EE Facebook Connect project, do you recommend:
restfb (http://www.restfb.com), or:
Facebook Java API
(http://code.google.com/p/facebook-java-api)
The requirements cover pretty much everything supported by Facebook Connect.
Completeness, ease of use, stability, etc are important. But what matters the most to us are the odds that the selected library flourishes and ends up being the winner, if there is such at thing.
Thank you.
With the new OAuth2 based authorization flow and the Graph API, the amount of "work" an SDK does has been greatly reduced. I'd suggest that you choose a library that does not try to provide very high level abstractions, and instead understand and leverage the fact that you're making HTTP API calls (for instance, for parallelization of HTTP requests). We recently released an Android SDK which while not related to your question, may be a good point of reference.
For full disclosure, I mavenized RestFB and have commit rights to the project. That said, I was in the same position some time ago, needing some Java library for working with FB's Graph API. Originally, I tried out facebook-java-api, but it didn't support all the newer APIs. I peaked into the code at the time and saw some inherent inflexibility that made it overly complicated to do what I needed so I looked around for alternatives. In all fairness to facebook-java-api, perhaps I just caught them at a bad time (around 6 months ago, there were only minor updates to 2.x and no 3.x in sight at the time. I see they've released 3.0.2 recently).
Anyhow, I then found RestFB. What I liked about it from the very beginning was how clean and extensible the code was and that it didn't require any extra dependencies. The basic Graph API objects are built-in and it's very simple to create new ones. There were one or two minor things that didn't work out of the box, so I opened issues and Mark Allen, the founder of the RestFB project, seemed pretty responsive with fixing them so I stuck to using it. More recently, I contributed Maven build to the project since I was keen on seeing the RestFB libs on Maven Central to make it easier for myself to use them.
We are in the process of selecting a workflow solution for a company that uses Microsoft products end to end. Given the news on WF4, in that it seems to be essentially a rewrite of previous versions, is it a wise move to back the current version or should we be looking elsewhere?
Ie - is the current version so bad that we would not be wise to try and use it?
Haiving just launched a project which .NET 3.5 and workflow I'd say that the current release of WF is good enough to use and run with. It has helped us to get a product out quickly (we have the usual feature creep and requirements changing weekly). However, I have a list of complaints with it:
The workflow designer will drive you insane because it is so slow (in certain circumstances) and re-arranges your state machines as it sees fit.
There is no built in upgrade strategy for keeping your old workflows running once you do a bug fix release. If you are going to use WF think carefully how to do upgrades early.
Itegrating with WCF (the send and recieve activity) hide the WorkflowRuntime from you this makes it very difficult to understand what is going on on the hood.
Its not easy to unit test them. There are ideas out there but none seemed particulary easy when we started this WorkFlow Unit Testing
I like the ideas and potential of Workflow based development, however I am not in a hurry to repeat this experience and would probably stick without it for long running processes. One place I would use it again would be in a short, complicated process (like a rules engine for working out prices).
Maybe it is a little late for you, but now that WF 4.0 is released in beta, other people thinking the same question can consider backing the 4.0 horse instead of 3.5 horse.
This goes some way to fixing the following problems:
•The workflow designer will drive you insane because it is so slow (in certain circumstances) and re-arranges your state machines as it sees fit.
[Designer Perf Improved]
•Its not easy to unit test them. There are ideas out there but none seemed particulary easy when we started this WorkFlow Unit Testing
[I think it's a little easier now, some of the introduction to workflow samples include plenty of unit testing]
My understanding is that Microsoft will provide backwards compatibility and/or a migration strategy to the new WF, so I would guess that you are safe to use it. However, I have heard from other developers in my organization that the current version of WF is extremely painful to use. If you have the budget (and depending on the complexity of your workflows), you may want to consider K2: http://www.k2.com/en/index.aspx
I, as a workflow developer, think that current version is painful to use. This is not surprising as this is a v1.0 software out from microsoft :)
I think you should first consider your expectations from a workflow software. Do you have a well defined list of expectations from WF? Acutally I am wondering content of such a list. Maybe we can help more detailed on each topic.
I don't know why people have such negative impressions about WF. Sure it has it drawbacks, but I thought it was pretty useful. The one major issue I have about it is the lack of support for upgrading existing workflow (bullent #2 in gbanfill's list).
Another point to use the current version is that "Dublin" (Microsoft new App Server) will be built on WCF & WF .NET 4.0 but will gladly host 3.5 WF's. So you will be able to migrate to that without a rewrite.
Just a quick note to mention that Visual Studio 2010 CTP contains a new updated WF designer as part of the Oslo objective.