Fabian is a Technology Leader working in Sydney, Australia. This Blog contains his personal opinions and observations on technology and software development.
I work with multiple OSes, programming languages and frameworks so here is a tip on keeping your git repos clean. I create a global .gitignore file to exclude platform related files (OS and IDE) and then when I create a new project I create a project specific .gitignore for the project related files which is specific to the languages and frameworks I am using in the project. Creating a global gitignore on a Mac You may name the file and place it where you want. I typically just name it .gitignore and store at '~/.gitignore'. Set it by running the following in a terminal: git config --global core.excludesfile '~/.gitignore' Example global gitignore Here is my global which I place at '~/.gitignore' Project specific gitignore GitHub have created a repo as a guide for what to include in your .gitignore for specific languages and frameworks: https://github.com/github/gitignore .
Good kick off point https://owasp.org/www-project-api-security/ https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html https://github.com/OWASP/wstg https://stackoverflow.blog/2021/10/06/best-practices-for-authentication-and-authorization-for-rest-apis/ Around the industry https://www.f5.com/labs/learning-center/securing-apis-10-best-practices-for-keeping-your-data-and-infrastructure-safe https://blog.axway.com/learning-center/digital-security/keys-oauth/api-security-best-practices https://curity.io/resources/learn/api-security-best-practices/ https://medium.com/apis-and-digital-transformation/best-practices-for-building-secure-apis-2b4eb8071d41 https://learn.microsoft.com/en-us/azure/api-management/mitigate-owasp-api-threats https://learn.microsoft.com/en-us/dotnet/architecture/microservices/secure-net-microservices-web-applications/ State of API Security https://content.salt.security/gartner-2022-predicts https://content.salt.security/state-api-report.html Serv...
Testing large, complex web applications is a monumental challenge. As applications grow, so does the test suite. Traditional test automation frameworks, often built on the Page Object Model (POM), can become brittle, hard to maintain, and difficult for non-technical stakeholders to understand. What if we could build a framework that was not only robust and scalable but also produced living documentation that the entire team—from developers to business analysts—could use? In this post, we'll build a production-grade test automation framework from the ground up. We'll combine the power of modern tools and patterns to create a solution that is maintainable, readable, and ready for the demands of large-scale applications. Table of Contents The Dream Team: Our Technology Stack Why This Stack? The Core Concepts Setting Up the Project: The Bluepri...
Comments