This blog post is part of an ongoing series encompassing the top must-haves when selecting an integrated solution.
The term “ease-of-use” undoubtedly carries a different meaning today than it did even a decade ago. Think smartphones and tablets for example. A simple tap of a button almost instantaneously delivers the application and content we desire – no training required.
While integration software may lag a bit behind our smartphones, it is still possible to implement intuitive and easy-to-use solutions that get the job done quickly and with minimal effort. You simply have to be mindful and do your homework before selecting a solution.
Integration software, particularly programs that meet very complex requirements, can appear overwhelming at first. And while you can begin using integration software without training, a bit of online or phone-based training can pay dividends as there are proper ways to navigate and leverage tools more effectively and efficiently. Continue reading
When choosing an integration software solution, do your requirements include the ability to make integration results or the outcome of the transactions, available to the customer services team, accounts receivable or the management staff? And when your requirements include business-to-business integration, do you also need to share results with your trading partners? Many times the answer to these questions is no, for a number of reasons including, but not limited to:
- Prior experiences where this functionality was available, but as a costly customization
- No need to expose this information to others
- Not aware this functionality can be a requirement of integration middleware Continue reading
Part one of this blog series discussed permissive and weak copyleft open source licenses. Permissive licenses allow you to use and make changes to the software without having to distribute the source code to your application. The weak copyleft licenses allow you to use the software without distributing your source code, but require you to use their license once you make changes to the source code (meaning release whatever you’ve changed). Part two focuses on the strong copyleft licenses, and I list some companies that contribute to the open source community. Continue reading
The past 14 years of my computer programming career have been a joy thanks to the existence of open source software. Using open source libraries allow me to create software quickly without having to implement certain tasks other developers around the world have completed. I’m able to dig through the source code to learn how certain technologies work. I’ve even become a better programmer because of reading other people’s code. When building a commercial product that uses open source software, educating yourself on the various open source licenses is mandatory to avoid litigation over how you use that open source software. The purpose of this two-part blog series is to give a brief overview of the major open source licenses and list some applications that use an open source license and companies that contribute and distribute open source software using the discussed licenses. The focus of these blogs is for companies that wish to sell and distribute their applications that use open source software. If your application will not be distributed to customers (such as in a Software as a Service scenario), then all but the last license (discussed in part two) do not apply. Continue reading
Class and object design can be a tricky thing. It’s not really something that can be taught or quantified. This skill is developed through years of experience. This may be more of an art than it is a science. No expert can come up with an exact formula on how this should be done but all experts can pretty much agree on what is a bad design.
A possible starting point of a process could be to develop a written problem statement outlining the issue at hand. This can be done by interviewing a customer or whoever the requirements are coming from. Once the problem statement is developed you will find that the nouns in the statement will turn into classes and the verbs in the statement will turn into operations. From there relationships between the classes can be derived. Statements like “is a” can denote inheritance, “has a” can denote composition, “uses” can denote delegation, etc.
A UML diagram should be drawn modeling what was discovered by the problem statement. It is also good to keep a catalogue of design patterns at hand so that a given pattern may be applied to a module of the software system. Remember that Object Oriented Software is about loose coupling, encapsulation, and reuse, which design patterns help enforce. Once the initial diagram is developed it is really more of a guideline than concrete fact at this point. When the implementation process begins new facts will come to light that haven’t been considered before which will ultimately force the redesign some components of the software. Once this happens the diagram should be updated to reflect the new functionality. This will create a software cycle that will bounce back and forth from implementation to redesign approaching a final version of the software.
This is really only a generalized overview of an absolutely monstrous topic in which there are many different paradigms and many different ways to go about tackling the problem. As a closing thought, keep in mind that a design is never really complete, that it can always be improved upon and made more robust, clearer, and more efficient.