22

The reason you're getting the concepts jumbled up is that the vendors are selling them in a package. But they are definitely separate concepts. An API Gateway provides a central access point for managing, monitoring, and securing access to your publicly exposed web services. It would also allow you to consolidate services across disparate endpoints as if ...


16

create a one extra project in which all common things are defined This is the exactly first step to share reusable parts - and its the easy part. The more challenging part is to decide if the two projects which are using the shared library shall have independent release cycles (or not), and if it should be possible that "project A" uses version 1.0 of your ...


14

I think warnings, which are not treated as errors, are useless. You get tons of them, therefore nobody bothers to look at them, and they miss their purpose. My suggestion is to fix them all, and start treating them as errors. Fixing them looks scary, but I think it can be done. A good programmer that would pick up this work will very soon figure out the way ...


13

Your solution is the right one. Put the shared code into a another project that builds its own JAR file, and use it in both projects. When building the JAR file, you may want to include the version in the name, e.g. in Debian style; libmyproject-shared-1.0.jar It doesn't prevent versioning trouble, but it should help. I've never used Maven, but I ...


10

I worked at a place that took 5 hours (across 30 machines) to run integration tests. I refactored the codebase and did unit tests instead for the new stuff. The unit tests took 30 seconds (across 1 machine). Oh, and bugs went down too. And development time since we knew exactly what broke with granular tests. Long story short, you don't. Full integration ...


9

Trying to cover failures like this with business logic and retries is in my view a mistake. You can always think up a scenario which isn't covered by your logic. In your case, case the DB write has failed because the network card on the box is non functional. So you cant send emails, or a response to the user, retrying wont help etc etc. Instead you should ...


8

Integration tests will always be long running as they should mimic a real user. For this very reason you shouldn't run them all synchronously! Given that you are already running stuff in the cloud it seems to me like you are in a prime position to scale your tests over multiple machines. In the extreme case, spin up one new environment per test and run ...


8

How do I nicely explain to a customer that if the message is really critical and time sensitive then email (SMTP) is NOT the way to do it. By knowing why it's not. Name one real need that the email solution can't solve. I can guess at a few. HTTPS is fairly good at securely communicating and proving you're talking to who you think you're talking to. But ...


7

A streaming app is an app that consumes a stream of data. A stream of data is transmitted data formatted in a way that can be useful even when incomplete. Since partial stream data does not require complete transmission this allows consumers to join and leave at any time. It also allows for transmission to be continuous, though it may start and stop on ...


7

Your incompatible Logger implementations cannot be linked because they have the same name. This leads to a simple solution that will solve all your problems: Incompatible versions should have different names. C++ makes following this approach comparatively easy because you can put those into separate namespaces, e.g. logging4::Logger vs logging5::Logger. ...


6

First, as the comments point out, you aren't really talking about realtime here -- that has a pretty strict definition and implies lots of stuff that isn't really on the table. You are talking about connecting two systems in a near realtime sort of manner. Anyhow, yes, the best bet would be some sort of message queueing solution here. The POS system would ...


6

I encounter this type of thing all the time, there are some unbelievable commercial SOAP/XML APIs out there. What I normally do is basically two things: Define a facade for the functionality my service actually needs. This is a simplified interface that exposes the things my service cares about in a consumable way. Create an adapter between the external ...


5

There are two sources of errors here: (a) numerical inaccuracies stemming from floating-point representations, and (b) general measurement errors, which in turn are either (b.1) calibration errors (your accelerometer has a skewed or drifting scale) or (b.2) statistical uncertainty. Errors from (a) are difficult, but possible to quantify exactly. However, ...


5

Solution B only works if you request the data from System A every time it is required by System B. Otherwise you cannot guarantee the information is up to date. This is not as bad as it sounds and is in fact the basis of all SOA architectures. The decision of whether to push (Solution A) or pull (Solution B) depends on the ratio of updates in system A to ...


5

The branch workflow sounds a lot like gitflow http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow and there are support tools around it. It is highly recommended. If there is only one tester, your testing workflow sounds fine, but if there are multiple people then development might move between start and finish, and of course testing should ...


4

Don't touch any of the legacy code. Find a way to suppress the warnings for now. Making seemingly innocuous changes to the code can introduce bugs in code which, I assume, has already been tested and is relatively bug free. By suppressing all of the warnings that are currently in the codebase, you can pretend to have a clean slate. Any new warnings ...


4

The fundamental problem here is that REST is not a standard. It is an architectural style for web APIs. While there are mechanisms to make these APIs self-describing, and there are web-service description formats, most APIs do not make use of these techniques – and why should they? That's a lot of enterprisey ceremony with very little value. Even once you ...


3

In order to do the mapping, you need something which uniquely identifies the object in the external system. This is exactly the purpose of an ID. If the external system uses mutable IDs, the system is broken. This includes the case where an ID of a removed entity is reused for a new entity. In order to have a hint that the system is broken, you can compare ...


3

I was reading C++ Coding Standards: 101 Rules, Guideleines, and Best Practices and the second of guidelines suggests "Compile cleany at high warning levels". It outlines a number of reasons why you would not want that many warnings in a program and chief among them are There is a potential problem in your code. Should have silent, successful builds and, if ...


3

The preferred approach towards customizing the Great Plains (GP) is to access data via database. You can write a application in any programming language you are comfortable with which can connect to a database. This is a risky approach though, but there are developers customizing GP in that fashion. The schema details for the GP database is not well ...


3

No, it's not an unusual requirement. It's common to expend significant effort to make upgrades as seamless as possible for the customer, sometimes even going so far as to purposely retain bugs that client software depends on. I've had similar requirements even in environments where upgrades are done quickly with a script, even if the dual code is only in ...


3

Ask yourself and your business very carefully, sincerely, and repeatedly, if it really needs to be real-time. As in, really instant? Are we talking about atomic, you can never ever have those two servers out of sync, not even for a microsecond? Or is there really some kind of SLA attached and the data can be stale for maybe a few milliseconds, or a few ...


3

If you built a house and you want to describe it to someone, would you talk about what kind of flooring material you used? About what kind of hammer and tools you used? About the plumbing? You might, but none of this has to do with architecture. Architecture is about what kind of rooms there are, where they are and how they are connected. So the first ...


3

Sounds like you have way too many integration tests. Recall Test pyramid. Integration tests belong in the middle. As an example take a repository with method set(key,object), get(key). This repository is used extensively throughout your code base. All the methods that depend on this repository will be tested with a fake repository. Now you only need two ...


3

The problem is the design of alerting that the integration of that specific unit failed. Take a step back from the technical solution and think about it from a business perspective first. What types of errors are expected to happen? Go through each integration step and list the things that can go wrong. Group these into different severity levels. For ...


3

I agree with everything CandiedOrange mentioned (including the how to explain x to y comment). It's all about the clients needs. I've built systems that rely on smtp email. It works fine and it suited the clients needs. And as far as I know it still runs, even now 7 years later. However, there is one downside here, as I see it. And it's the response. In a ...


3

Apache Kafka works in realtime, and is somehow in vogue for solving the subsystem communication problems that used to be solved with centralized databases or queue management systems. As to the XML, there shouldn't be any errors if a plain-object model and an adequate library are used to translate objects from-and-to XML. But the preferred format nowadays ...


3

If you don't want to add a new tool then use what you have. I like that task descriptions are editable in most ticketing tools. Task: 54328 - Make "Number of Dependents" spinner stop allowing negatives. Description Spinner fails to prevent negative input. Disallow this before user can click OK. [x] Find relevant source code: TaxGUI.asp [x] Correct ...


3

I'm assuming you have a small team and a limited budget, so my answer assumes the following is true: Maintaining 2 separate applications would be a big strain on the team The work to integrate the new product is non-trivial The old product is nearing end of life or is obsoleted by the new product which does the same job better At this point you have to ...


Only top voted, non community-wiki answers of a minimum length are eligible