Measuring the user experience is key to a successful app and a bad user experience can even cost a lot of money. Therefore, you should always assume app improvement as a continuous process that starts with monitoring and needs to be tested. This post focus on Monitoring and my top 4 mobile app monitoring tools.
There’s definitely some usefulness to the Lyskov substitution principle (LSP) concept. It will make your code highly replaceable and provide a very nice dev time trade-off. You can spend more time in the design process, rather than in unit test implementation (you’ll see why!).
QUIC focus on handshake optimization (very important!) but fails to truly revisit transport protocols at their essence (the transport!). Why is this important? Because traditional transport techniques have been defined in a wired-users world. That world is long gone, with unreliable and unpredictable wireless links dominating user experience. Are there other options? Yes: erasure coding, instead of ARQ.
Content Delivery Networks (CDNs) first appeared in the 90s, deploying the infrastructure that enabled caching. They are the ones responsible for placing the replicas of the most frequently accessed content near the end-users (at the “edge” of the network), through a network of edge servers. We could think that it solved all our problems, but there are still a few issues that cannot be solved by caching-based solutions.
Software Quality Assurance (SQA) is often seen as a way of preventing bugs or defects in manufactured products. It is basically the process of verifying whether a product meets the required specifications and customer expectations. When it comes to software, it is important to underline that Quality Assurance (QA) is not only about functional testing. Quality is more than that.
Personally, I consider Agile a philosophy that will help you create your own development methodology. There are, however, a lot of Agile methodologies that you should have a look at and learn from, before implementing it in your workplace.
Think about a client that uses some plugin or API that is not your latest version to communicate with your servers. Any feature changes that you introduced in your latest version should not break backward compatibility, so the client can still communicate with the server. The Open / Closed principle (OCP) is all about this, how you should develop modules for which you can easily extend logic.
I can’t understand why this new Chrome update was so “controversial”. First, because after updating Google Chrome, changes were not so evident. Second, because its already 2018 and HTTPs is so easy to deploy that should be a must-have in all pages and APIs.
If your classes do not follow the Single Responsibility Principle, chances are that you’ll have “God-like” classes with thousands of lines and multiple responsibilities. This means you’ll probably end up changing a bunch of code lines that don’t need changes and introducing some bugs along the way.
Many times, we don’t know if the project is going to be successful, if it will generate a new product or simply if it will be a new feature in one of our existing solutions. So it seems rather heavy to enforce this new-born child to inherit a large portion of our code infrastructure (not to mention it could skew the actual development of the project). Our game plan, when we start something fresh, is to have minimal dependencies from our codebase.