Hello dear readers. Welcome to my last blog post about the Apprenticeship Patterns. This is the 10th Pattern that I really found interesting and wanted to share with you all.

You are graduating, you probably have a job offer (or a few) in the table, you are ready to start this whole new journey and you think you have a good background to create a successful career. YES you do and Congratulations, but it doesn’t end here. You have worked hard to be here but you still got a lot of work to do.

After you Find your Mentor you will see that the Mentor will be giving you different exercises for you to work on based on your skills and weakness and you will see that every exercise will teach you something better or perfect your skills. When you start working in the company, you will face challenges in every project but don’t stop your exercising outside of work. I feel like in companies you apply a very specific knowledge and you would want to be on top of the new stuff that come out if you want to have a good career.

I really like the title of this pattern ” Practice, Practice, Practice”. I used to have a Math teacher in high school and she was always saying “It’s 99% hard work and 1% talent” and I totally agree with her now. That’s why the practice should never stop, doesn’t matter how far up you have gone in your career.

Also look at the bright side, while you just pick random exercises or small projects to work on, you don’t have to worry about deadlines and no pressure. You will notice at the end how happy you will feel about what you have worked on independently.

So just like the authors of this book suggest, go online and find different problems to work on. If you want to feel more challenged find coding competitions and enter them. Don’t worry if you don’t win. You will definitely learn something out of that experience.  After a while go back to where you started and you will see how you have progressed. my last advice you all of you would be: don’t just settle when you start working in a company. Keep growing outside of it. Practice, Practice, Practice…

Hello dear reader. After explaining what API is, now I would like to talk about Architectural Styles for API. One of these styles is called SOAP.

SOAP stands for Simple Object Access Protocol. SOAP is a standard based Web services access protocol that enjoys the benefits of long-term use. SOAP is developed by Microsoft.
SOAP relies exclusively on XML to provide messaging services. Microsoft originally developed SOAP to take the place of older technologies that don’t work well on the Internet. These technologies are bad and fail because they rely on binary messaging; the XML messaging that SOAP employs works better over the Internet. SOAP is designed to support expansion, so it has all sorts of other acronyms and abbreviations associated with it, such as WS-Addressing, WS-ReliableMessaging, WS-Policy, WS-AtomicTransaction, WS-Federation, WS-Coordination, WS-Security, and WS-RemotePortlets. In SOAP you can only choose to use the pieces you need for a particular task.As we know, in some programming languages, you need to build requests manually, which becomes problematic because SOAP is intolerant of errors. However, SOAP provides shortcuts to help in this issue. The difficulty of using SOAP depends on the language you use.
One of the most important SOAP features is built-in error handling. If there’s a problem with your request, the response contains error information that you can use to fix the problem. An interesting SOAP feature is that you don’t necessarily have to use it with the HyperText Transfer Protocol (HTTP) transport. There’s an actual specification for using SOAP over Simple Mail Transfer Protocol (SMTP) and there isn’t any reason you can’t use it over other transports.
As SOAP is an ordinary XML file that consists of the following parts: 1. Envelope, which is the starting and the ending tags; 2. Header, which it allows you to extend the SOAP message in a modular way; 3. Body, which contains XML data that the server send to the receiver; 4. Fault, which carries the information about errors occurring during the process of sending the message.

SOAP is mostly used for enterprise-lever web service because that require high security. Some examples of SOAP that I found online were: financial services, payment gateways, identity management and telecommunication services. Also another feature of SOAP is that the API calls can not be cached. The biggest disadvantage is the poorer performance, more complexity and less flexibility.

I didn’t know SOAP existed until I searched for REST (the next blog). The reason why I choose to write about SOAP is that it is a wide used architectural style for API and it has its own place of use, places or situation where REST can not be used.

Hello dear reader. Welcome back to my blog. We talked in the previous blog about Test Driven Deployment. Now it is time to talk about Behavior Driven Deployment. Behavior Driven Deployment is a software development methodology that combines practices from test-driven development and domain-driven design. As we mentioned in the last blog test-driven deployment focuses development on short, cyclical iterations in which (failing) tests are initially created that define the wanted functionality, and only then is actual code written that ensures those previously-failing tests can now pass. Domain-driven design in the other hand, centers on the concept of domain and domain logic. Thus, DDD practices attempt to simplify the terminology in the project scope by focusing and defining everything in the application as real-world objects or concepts that most people are familiar with.
By the combination of TDD and DDD, Behavior Driven Development aims to simplify development trough the use of a common domain-specific language.
As behavior driven development is derived from influenced by TDD, many of the same benefits apply to BDD as well. BDD it reduces regression. When you have a full suite of tests being continually executed, and with new tests always being added, BDD reduces extremely the likelihood of regression bugs popping up as the code is in constant monitoring and testing.
BDD also improves team communication. Since there is a common real-life basis for phrases and terminology when discussing a project, BDD can often improve communication across the entirety of the team.

BDD has also disadvantages like it requires specifications before development and relies on constant outside feedback.

Personally, I like TDD testing better as the code does what you are testing and believe me when I say that the documentation and specifications are bad for a project. There are usually lots of misunderstanding in the specification of a project. It also depends on the project and the company. Thanks for being my reader again.

https://docs.cucumber.io/bdd/overview/