Tag Info

New answers tagged

-1

The job is not right for you. Low quality code written "because there is no time, clients are waiting, a bug should be fixed overnight, the company is losing money on this problem, a manager is pressing hard" is a symptom of a poorly managed company. If you are willing to take pride in your work and write high quality code, then the best thing to do is ...


2

The important thing is to develop an open, transparent and trusting relationship with the client. The customer needs to understand what your challenges - and cost - are to work in the manner you are being forced to work in. At the same time, you need to understand why is it that the client cannot deliver in a predictable manner. Once there is appreciation ...


0

In the current state-of-the-art english, "backend" is not defined on the context of systems engineering, therefore, no synonyms or antonyms. In the current state-of-the-art systems engineering "backend" is generally understood as everything that a user does not directly interact with. In another words, it's all that infrastructure only reached by servers. ...


1

This is because "backend" can mean a lot of things. Without context it has no meaning. For instance: In a CMS it is not uncommon to actually call the administrative interface "the backend". Try a search for "Wordpres backend." and you'll see what I mean. Wikipedia list of front and back ends


4

The term "backend" is not offcially defined, so there is no "real" backend. For example, in my current working context, I would call the database a backend component (even if it does run on the same machine, maybe embedded in the program's process), but not a "data access layer". So my suggestion is whenever you use the word backend, give a clear ...


2

Well... this happens all the time, and going agile is not going to fix the issue, rather you could get the web service definitions / contracts finalized. At this point you could actually start to build your system with mocking of the client web service using some tool like SOAPUI. Once the customer service is up and running, you can actually test it. Of ...


3

I would take one of two views, depending how confident I was that I was talking about the same thing as the original reporter: 1) Since the reporter is no longer available, deem that the bug in question means whatever it was you fixed. If it helps, attach test cases to make clear what failures you found. Describe in detail on the bug report what it was you ...


7

I read this as more a question about the practices around how to handle an unverified bug (using github's issue tracker) than anything else. To me, that is a rather straight forward answer based on other issue trackers I have used. Github doesn't force anyone to use any workflow and this makes it very flexible... and rather useless in its default ...


10

Your main question was already answered, but you also asked about documenting the process and that needs answering too. The solution I've seen in many projects is not to put it in the project's README.md, but in a special contribution README - a README file for contributors. This file describes everything you want the people contributing to your project to ...


44

This is a dilemma: you cannot close the issue as "fixed", because you don't actually know if it was fixed, or at least even if some issue was fixed, you don't actually know whether this was the issue the reporter was talking about. On the other hand, you don't want to leave an issue that might have been fixed open, especially if you won't ever be able to ...


0

This is a difficult problem. You can try to solve this by using feature branching - each new feature is developed in its own branch independently from the other features. You can then have "test" branch where all of these feature branches are merged so that customer can test all features at the same time . When feature A is ready, but B and C are not, you ...



Top 50 recent answers are included