Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
With web APIs like Facebook constantly being updated and changed, any given change may take me a while to implement in terms of working out what has changed, and then updating it/correcting it.
If during this time a user cannot logon for example, they are not going to put their trust in my website.
So, how do you manage your dependencies on other services to ensure that if it works now it will work forever?
Well, frankly what you are asking for is that Facebook freeze their entire API and Graph implementation. This simply will not happen. In an ever changing technological world things are going to change. We as developers for a 3rd party platform are responsible for keeping up to date with any changes that 3rd party platform makes.
If you want to keep track of all the changes that Facebook are making to their API's then you should take a look at the Developers Roadmap. They list here all the changes that are being planned.
For serious changes, those what would essentially "break" the current functionality, Facebook guarantees at least a 90 day notification, before the changes are made.
Taken from the Facebook developers roadmap -
In the spirit of openness and transparency and to adhere to our
Breaking Change Policy, we publish this roadmap to help
developers plan for changes that may require code modifications. Like
all roadmaps, it may shift slightly, but we will share insight into
what is happening as details become available. We encourage developers
to subscribe to our blog, where we announce rollout plans and
timing.
Given all of this information, there are still things you can do to make sure your users always have access to your site. One thing would be to provide an alternative login method. It's really useful to be able to hitch a ride on Facebook authentication and seamlessly integrate your site's login with theirs, but what happens if one day Facebook (for some reason) goes down? That would mean that your users would be locked out of your site too! Consider offering an alternative if it is applicable to your situation.
Communication is key.
Most respectable web API providers (like Facebook Graph) have a developers blog, as well as mailing lists that provide feedback regarding upcoming changes to the API. Chances are, they don't want to break your app as much as you don't want it to break. So read the blogs, and/or subscribe to the mailing lists. And take note about upcoming "breaking changes" (as they're called.)
Additionally, it is up to heed their warnings and suggestions. If they say that a particular API call is deprecated, then there is a good chance that it won't be there after the next update. If a call you're making is deprecated, then make early strides to find an alternative method.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
What exactly is backend code? Is it just APIs? Is there business logic in the backend?
For instance, if I have a timesheet app and the user enters their time for the day, is the logic to add that information to the database all in the frontend? And the backend is just for exposing an API to add/update information to the database? For this simple timesheet app, generally speaking, what would be in the frontend vs the backend?
This is a very broad question/topic, but I'll try to explain my view on those terms and how to decide where to put what:
In general, the "front-end" is what the user will see. To make this possible, that code has to be "stored and executed" on the users device. I'm quite certain that this means (experienced) users will be able to look into the code of the frontend and might be able to understand how it works. (I'll later explain more about why that is relevant.)
The "back-end" on the other side is usually provided as an "as is" service that somebody is offering, which is reachable via one or multiple of the many available communication protocols and its interface is usually documented in some way, even if it's not public. The most prominent examples nowadays are REST APIs and Graphql APIs.
As you already mention, centralized state management (e.g. storing data) can be an essential part of that (, but it doesn't have to).
When "making a call" to the back-end, some code gets executed on some server and the response (if any) is the only new information the frontend or user get to know.
What goes where?
There are many aspects to consider to make the decision what part of the code goes where. There is no silver bullet: I'm sure examples of all possible combinations can be found.
There can be many different front-ends for a single back-end, based on user preference (e.g. browser based, mobile apps, command line interface, ...).
They can have different release cycles and update mechanisms, so changes to the back-end might need to stay backwards compatible.
For security, operational or data consistency reasons, you might need to implement handling of wrong/invalid input in the back-end, especially if the (kind of) communication protocol changes. Especially since offering a frontend also means that it's possible to know how to call the back-end, so it's also possible to call it differently (be it on purpose or by accident).
Since operations between front-end and back-end are most likely async, certain error handling (like connection issues) can only be handled on front-end side.
Authentication and authorization / secrets management: If you back-end is only an API to the database, it needs to know the right credentials, so they need to be delivered to the user in some way and can be inspected (and potentially "mis"used)
same for business logic: there might be intellectual property or strategic reasons for not delivering it into the hand of users or potential competing companies.
And of course you need to consider how much resources you have available to implement a solution that suites your needs.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have looked at many articles regarding REST and its design implementation for an API. I have a couple of questions however, and maybe they are simply opinionated as there is no "one fits all solution" to REST or API development in general.
Note that these questions are in regards to contacting and receiving requests from an SDK.
My questions are both in regards to the URI form, as I believe it is called. I have seen this represented in a few ways, but my big concern is about versioning and "dynamic" sections.
For my first question (version'ing) I have seen the following approached used often.
/customers/accounts/V3.4/customer_id/1234
/customers/accounts/V3.5/customer_id/1234
Developers would implement this by keeping a general version class, and as they make calls it would grab whatever version the developer has setup. So if they ever wanted to move up to a new API version they would just have to modify the V#.# in one location. I am wondering how good of an this idea is in practice, especially for an SDK. My general thoughts are that this is OK. I believe this as versions are clearly pointed out. If a change needs to be made it is simply a matter of updating your version's call. With an SDK in mind, using an old API won't break anything as if they do not update for awhile then their API request will still be fine, but will route through an older endpoint.
Question 1. Is version'ing using the approach above okay for API updates? Pro's/Cons?
The second question about dynamic values can be seen as follows.
/customers/V4.3/{customer_id}/account
versus
/customers/accounts/V3.4/customer_id/1234
I am not sure if there is a better trade-off to having dynamic endpoints versus hard coding them as listed above. I say this because what if we have a scenario where we wish to add details to the "account" page.
In the above example customers/V4.3 would not have to be updated, as it still contains the same user list midpoint. We would be able to update the account API without causing a version change. (forgive me if that is a terrible idea). But with the second option we would have to update the versioning as that is a midpoint
Question 2. In the example above, is it better to focus on more static or dynamic endpoints?
Still very new to learning about this, forgive me if I made some bad assumptions or conclusions on API design.
What is the problem with using Parameters ?
IMHO
Things that are dynamic or can change in future should never be part of the URL path.
This is why parameters exists. And the benefit is :-
http://example.com/api/resource/?customer_id=1234&v=3.4
Would be treated the same by your script as:-
http://example.com/api/resource/?v=3.4&customer_id=1234
I don't know the context of the SDK, but I would think hard about requirements before allowing API users to choose the version & perform actions.
Also please take a look https://stackoverflow.com/a/17999251/2489860
This is one of those RESTful debates that can go round in circles. You have three options for specifying the version: the URL, the content type or a custom header. All of them will be considered "wrong" by some folks.
Troy Hunt's written a pretty good discussion around the pros and cons here:
http://www.troyhunt.com/2014/02/your-api-versioning-is-wrong-which-is.html
However, I wouldn't necessarily be too quick to reach for versioning as a solution. You may want to consider side-stepping the issue by using more tolerant consumers, investing in more up-front design or applying the open/closed principle to your APIs.
This argument is expressed in more detail here:
http://martinfowler.com/articles/enterpriseREST.html#versioning
It includes a great quote:
"Some people, when confronted with a problem, think "I know, I'll use versioning." Now they have 2.1.0 problems."
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I wanted to ask you, experienced programmers, a question that bothers me recently. I'm a second year student of the university of technology, where we spend a lot of time learning how to code. I found creating small but practical applications the best way to learn, and sometimes I would like to give them for free to someone else. And here the problem appears. If someone want to use it but is afraid that the app is not safe, I don't know any other way how to prove that it's not harmful but to show the source. It's not a big deal for me since those apps are not that big and complex, but I'm wondering if there is any way to show that the program is fully safe without sending the source code. It's basic stuff I guess, sorry if it sounds stupid an obvious.
Thanks.
Edit:
By "safe" I mean it's not a keylogger or anything like that.
Even if you strive hard to keep your app safe, when the underlying OS is vulnerable, it goes vain! So if you expect that trust, probably, if you have restrict your app to be in platforms, that you believe to be trustworthy.
For keyloggers you mean, show only virtual keyboard of your own app, donot use the system's default. Encrpyt evrything (data) you send from your app. Create a checksum value for you app, and when someone tampers it, make sure , your app recognises it and makes it unusable, till reinstalled. Have a pre installer to validate the platform, your app is being installed.
Never allow, external sources to access the app content. Secure your critical content, in a encrypted container.
may be the below link, provides some more insight!
http://www1.good.com/good-dynamics-platform/
Basically, this is the same question as "how do I know anything is safe". Consumer appliances get recalled periodically, but we trust that they aren't deliberately designed to catch fire. If you aren't sure you trust it, you run it only when/where you can keep an eye on it and/or isolate it so it can't damage more than itself, or you throw it out.
If people don't trust the source of their code, they have two choices: Don't run it, or run it in a highly isolated environment.
The latter is a large part of what the Java Applet and Java security environment is about, but of course that does require that you trust whoever wrote the browser and/or set up the security environment to have done that successfully, and you have to trust that those don't have bugs that can be exploited.
If you're talking about products... There have been various practices published from time to time regarding how code should be written, and tested, for robustness. These days those may include "white hat" security attacks along with full code inspection and so on. If you can show that you're following these practices, it may reassure some folks who otherwise wouldn't trust you... but doing them with full rigor can be expensive, so part of this is knowing what your customers expect and/or will tolerate.
In the end, the real answer is that you need to start by writing trustworthy code, then know what the customer's concerns are and make sure you can meet their requirements either by delivering perfect code and/or by delivering above-average service and/or by being... no, I'm not going to take a cheap shot at that company this time.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
So if a user story is a something nebulous like:
As a sales rep, I would like to capture the contact information so that I can follow up later on.
I'm not even sure if that's a valid user story but I'm sure it's close enough.
Then there are details/tasks for implementing that user story.
And I'm sure "The sales rep should be able to tab from one textbox to another." is one of the requirements. How do we capture/track this? Is this part of the user story or is it something that's to be considered separately?
A user story captures the essence of a feature, not the details, a story is a support for the discussion.
So, to answer your question, details are transmitted orally during a discussion, because face to face discussion is the most effective communication media. If you feel the need, details can be captured as notes on the back of the card (if you are using cards) or... in a "notes" field if you are using an electronic tool. Actually, I usually use a "how to demo" field too to capture a high-level description of how this story will be demonstrated at the sprint demo and use very brief "notes" for any other info, clarifications, references to other sources of info, etc (credits to Henrik Kniberg's famous Index card generator). If find this very handy, especially when using executable specifications.
PS: your story is perfectly valid and its a good practice to include the benefits in your template ("As a role, I want action so that benefits").
User stories should be short statements in 1 to 3 sentences.
http://en.wikipedia.org/wiki/User_story
I want to be able to tab from one textbox to another is another user story.
You can track these things in a tool like www.rallydev.com, or just any type of task tracking tool (SharePoint, Excel even ... etc.).
Next thing you do is prioritize.
Just taking a rough stab...
As a sales rep,
I want all data entry and navigation to be accomplished using the keyboard
so that I don't have to take my hands off the keyboard
(and so that we comply with accessibility guidelines).
Or
As a business,
We want all our products to be fully usable using only keyboard input
So that we can sell to customers who require accessible software.
The first part belongs to a "business requirements" document (usually written by a business analyst). The first generations of this document are quite high level, but the final versions (several iterations later) are pretty detailed.
http://www.tdan.com/view-articles/6089
The second part (about tabbing) is part of another document - "UX spec" (shows all screens and describes user interaction). This one is usually written by a different person/team (Product or UX team).
http://uxdesign.com/ux-defined-2
http://www.uxmatters.com/mt/archives/2007/05/sharing-ownership-of-ux.php
Yes, that is problem we also have a lot. On the one hand, user stories need to be conscise, on the other hand all the nitty gritty details must be put somewhere.
We use XPlanner, and we solve this by putting the short description into the text body of the user story. Then we use XPlanners "notes" feature (arbitrary text or files that can be attached to a user story) for the details.
That way we can add as much information as necessary to a user story, without cluttering up the user story text itself. You can also refer to external documentation, if you don't want to have everything in XPlanner.
This approach works quite well for us.
Agree with others, that this is viable story, but capture the (derived) requirements may be better captured elsewhere.
Software Developers and Business types are familiar with different terminology some what may simple to understand by one (data structures) may mean nothing to another. The User Stories is a tool or a means by which business user can convey a message as a starting point which is expanded on (with tests, details, etc).
Oral Communication can be effective, but the effectiveness is dependent on the receivers ability to hear and comprehend the meaning of the message. This is where oral communication can fail. Different types of communication offerring more or less formal forms of communication. Vocal communication is an "informal form of communication" which risks the message being misheard, misinterpretted, and misunderstanding. Just like the game played as a child, where one child whispers a message to another child, who tells another, until all have heard it...When the last child tells the message to the group it usually has been misinterpreted then misinterpretted again, causing a degraded message.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm trying to land my first programming-related job, and I found a website for a company which is accepting resumes for an eCommerce development position.
This is the requirements they listed:
To be proficient in:
HTML (hand-coded)
CSS
PHP
Javascript
MySQL
Preferred skills:
PEARL
Linux
The fact that they (unless they're actually using the PEARL programming language) misspelled perl and have a fairly bland portfolio aside, I can do all of this--I mean, I need to touch up on my Javascript and learn a bit more MySQL--but I can do all this, and I'm sure I can pick up perl in no time. But I was wondering--what exactly does an eCommerce developer do? Is this like, building shopping carts? User login systems? Or does it just mean doing everything except design on corporate websites?
eCommerce has one big word that goes with it Security.
Do you feel confident writing secure code? Bearing in mind that your code will be handling the users credit card information.
Now, there is alot that goes into building an eCommerce solution from the ground up
Product Listings
Adding/Removing Items
Sort by size/shape/price/color/...
Search
Filtering results
Shopping cart (harder then it sounds)
Database or Session?
Adding/Removing Items
Checkout
Integration with payment API
Reporting
Inventory
Security
XSS
SQL Injections
I would suggest that ecommerce is so much more than a specific technology. ECom is more about how the database is built and the features that are required. There is a good book that I read 10 years (a long time) ago that goes into ecommerce with asp classic. But there are many new ones using newer technologies here.
The big key is how you structure your data, products, options, orders, order details, credit card/user data, etc. Also, the various ways of processing transactions. How to handle order pipelines. When to offer navigations away from the current page and when not too. How to make product recommendations. Dealing with tax API's and shipping API's. You might consider downloading DashCommerce (a .net application) or something similar that fits your preferred technologies to see how they have set things up. Install something. Get it set up to feel the pains for data management. ...also to feel the pains of navigating a shopping cart (adding products to the cart, updating the cart, checking out, setting up an account or having an anonymous checkouts).
Being an commerce developer generally means knowing how to work with Verisign (now paypal) or similar payment processing. How to intercept fraudulent transactions and deal with them appropriately. How to work in a high transaction environment (caching, tierd architectures, queues, web services). Cross linking products based on user history/profiling to maximize transactions (think candy at the check out stand of a grocery store). Knowing how to work in a secure manner with sensitive data which generally means encryption techniques, setting up DMZ's, working with proxies, etc. Take a look at using some form of a rule engine for order pipelines so that your business rules are separate from your application logic. Understand coupons schemes, discounts, etc. Frequently ad campaigns are heavily used for generating side income.
Ecommerce can be a big topic!
It all depends on what you are working with.
I have been working as an e-commerce developer for half a year now.
I have used the Magento platform for all of my work.
Since standard Magento is already very secure you won't have to do much security code.
Mostly you change the layout and the design of the standard Magento shop and add any new features the client wants.
Most of these can be achieved by downloading custom modules built by other developers or you can build them yourself. Building a Magento module the right way is quite difficult for someone who is kind of new to programming or new to Magento.
I know this topic is rather old, but i thought someone might still benefit from this answer.