Do we have any updated on Service fabric limitations which are mentioned in the below link?
https://azure.microsoft.com/en-in/blog/azure-service-fabric-mesh-is-now-in-public-preview/
Most of the limitations are described in the FAQ in the docs, it should have the most recent information when these limitations are changed, the last update is as old as the blog post you linked.
The other source of information is the github issues list
And the Twitter #servicefabric
And then, the SF blog
Technically, not many updates has been released since then,
I've heard they are currently focused on next Conference, probably they will have more updates after that.
Related
I am not a 100% sure if this topic is "off-topic" but I couldn't find a more suitable stackexchange for my question.
I am working with the Maximo API and use the IBM docs regularly to help me program. 2 days ago I could still reach the docs such as:
This gave me a overview of the classes, fields, methods etc.
Today I tried reaching the following docs:
But the following message shows up:
Now, I can't possibly believe they have deleted all docs so I assume they might have moved them but I just cannot find them. I tried the search function on the IBM website but no results show up.
Does anyone know where they could have moved them?
PS: If this is off-topic for stackoverflow, could a moderator move the topic to a more appropiate exchange? Thanks in advance.
The Maximo api or JavaDocs can be accessed and searched using tools such as Dash (for iOS / MacOS) and Velocity (for MS Windows).
You can also download a copy from IBM for use locally from IBM Maximo JavaDocs
Hopefully once IBM finishes updating its website the JavaDocs will be available there again for reference online.
I have just published the Maximo 7.6 JavaDocs on my blog so they are easily accessible and searched from Google.
So, I stepped once at this problem. I had offered a website that used the SoundCloud API. Everything worked properly. Content was extracted from the JSON and placed in the layout of the website. However, I received an email one day from the owner of the website, which indicated that the website did not work properly. I then came out to investigate and came to the conclusion that the "problem" was not on my side, but at SoundCloud's side. I studied on the API page of SoundCloud and came to the conclusion that the API had received a major update, making the link with SC and the site no longer worked.
Lately I'm trying many new APIs to, including those from Instagram and Dribbble. I was therefore wondering if it is at all possible to ensure that such problems can be reduced in the future or it might be appropriate API pages of this third-party APIs to monitor?
There's no "right" answer. After many years of using and maintaining many APIs here are some of the conclusions I've come to:
The best providers let you work with a specific version of their API whose interface and expected behavior never changes. They might release bug fixes and new endpoints, but you can be confident that as long as the API is supported it will not break your system.
A good provider will provide an end-of-life date for each version of their API. It's up to you to keep track of when you need to update.
Paid services will often be supported longer than free services. Plus the contract / SLA will guarantee it remains available for a specific amount of time.
The most popular APIs often have mailing lists and/or blogs. For those that offer it, sign up to be notified of updates. For those that don't you'll have to monitor their blogs or news posts. And I suggest not using any service that would drop support for an API version without warning.
In the past, I've been using the Delicious API available under feeds.delicious.com. When running this code today, I found out that the corresponding hostname is not available any longer (checked first time some days ago). I've already asked Delicious support directly about the state of the API, but not yet received an answer. So I thought anybody here might have more recent information, whether this is some temporary outage or the API has been cut completely?
This was likely part of the rollback to Delicious's old architecture in January 2016:
Fortunately for us, the version that the javascript site replaced has been kept alive at previous.delicious.com. This was built using a much more traditional framework, and it’s great! In fact, many of our longtime users have continued to prefer it over the main site, and frankly, so do we. Therefore, we are switching to this platform for our main site, and this transition will position us to quickly iterate in our ongoing efforts to keep Delicious thriving.
The auth URL on the documentation's OAuth page (delicious.com/auth/authorize) 404's for me as well, so I have a feeling this has indeed been retired.
I am using POSTMAN collections to test my API before opening it up. I work with a team of developers and we would like to share/add/edit our collections amongst each other.
Doing this in source control is proving slightly tricky as can be seen in this comment on the GitHUB page:
This issue still persists in Version 2.1.1 (packaged)
The order of requests might be deterministic now, but the diff of an exported collection from two different machines and users includes data that are not related to the collections exported. The diff is full of owner and other id conflicts if there are several people working on the tests at the same time.
What is the best way that we have of putting this data in some sort of version control system? Any suggestions otherwise?
Putting it in a VCS undoubtly will give you some headaches as you mentioned. Your best bet is to use Postmans functionality to share collections. Here is from the documentation found at https://www.getpostman.com/docs/sharing
Starting with Postman v0.9.3 you have the ability to share and manage your collections more effectively. The first thing you will have to do is create a Postman account. You can create one using your email ID or a Google account. Once you are signed in after creating an account, the collections you upload on Postman are linked to your account. You can delete them later through the "Shared collections" item in the navigation bar dropdown.
Collection v2 format removes most, if not all, problems with portability.
http://blog.getpostman.com/2015/06/05/travelogue-of-postman-collection-format-v2/
The format must be highly portable so that it can be easily transported between various systems without loosing functionality.
Source Control in Postman
The question about sharing collections so that you can collaborate with your teammates has been answered a few different ways, as described in other answers of this question such as by sharing the collection or by syncing to a team account.
Version Control in Postman
The other part of the question was about putting the Postman data into a version control system. Postman introduced some version control features for the paid team accounts, like being able to restore collections to a certain point in the activity feed.
The paid team accounts also get integrations to sync their collections to their own version control systems like GitHub for example. If you're on a free account, you can use the Postman API to build your own similar integration to update the collections.
This blog post talks about some of the version control features in Postman.
UPDATE: Postman released forking and merging in Postman app v6.7.1 so you can manage version control in the app.
To automatically share your existing postman collection you can use Postman Pro.
It is a paid service provided using which a team lead can purchase the complete pro- scheme for his team and work as an admin.
Postman pro enables the following and many more:
Any changes in the API are automatically reflected in Postman for all member
Members subscribe to the collections from the Team library and get notifications of any changes.
For more information you can refer:
https://app.getpostman.com/dashboard/team-upgrades
This is what I use with my team of automation testers.
I just started developing an Intuit App yesterday and was really getting going on integrating with QuickBooks Desktop. Then today I logged in to continue work and was greeted by several missing pages on Intuit's IPP site and a link that says "Deprecated QBO V2 and QBD V2,V3". The only API that appears to not be deprecated is QBO V3.
I cannot find any announcement from Intuit about any upcoming deprecation. Does anybody have any info on whether I am safe to continue developing my app to connect to QBD or do I need to talk to our accountant to move over to QBO instead?
EDIT: I have marked Jarred's answer as the accepted answer because he associated with Intuit and answers my specific situation. Also check Charlie's answer for additional details specific to other scenarios.
I interviewed several people from Intuit at the Sleeter Accounting Solutions Conference this week, including (amongst others) Dan Wernikoff, Senior VP.
I'll have an article in my blog on this (http://www.sleeter.com/blog/) next week - I'm transcribing my recordings and clarifying points.
There are a LOT of points here, but to address what you are looking at -
If you are writing an IPP app using V3 for QBO - no problem (and in fact, some good news there).
If you are already published with IPP using V3 and Sync Manager for the Desktop, you will get continued support but don't expect any advancement there (unless you are someone big like American Express).
If you are NOT already published with IPP for the Desktop - the SDK is your option.
And there is a lot more info about this coming out
MINOR EDIT AT A LATER DATE: If you have been working with IPP for the desktop you MIGHT get approved to continue - no guarantees on that (but it seems they might be lenient). But In my opinion you can't expect any significant new features (as in, more data access) moving forward unless you are a significant partner with a contract with them (such as, American Express).
Intuit will not prevent you from going live with your application that you have spent the last 6 months working on. We have a set of guidelines for grandfathering in developers who have invested in using the v2 REST API for QuickBooks Desktop.
feel free to contact me directly if you have more questions.
#Charlie if you could correct your statement regarding if you are NOT published then you need to use the QBXML SDK. That is too generic, we will evaluate each developer on a case by case basis.
regards,
Jarred
My writeup on this subject is available at http://www.sleeter.com/blog/2013/11/quickbooks-software-integration/
Note that Dan Wernikoff, Senior VP at Intuit, has been leaving comments in several of my articles in the blog.
Blair, you have a reasonable concern. However, given the REASONS that they made this change, I would SPECULATE that Intuit won't be pulling the SDK. What isn't clear, at this time, is HOW MUCH support they will give the SDK moving forward.
And, as we have seen for several years now, things can change...