If you are familiar with iOS trending topics, you certainly already know VIPER. It’s an alternative to MVC (Model View Controller) pattern and it was already explained in our blog. If you haven’t read yet, I strongly recommend you to do it.
There is a lot of content on the web talking about the VIPER miracles and how this new architecture is much better than the previous ones. But you always have to ask some questions before putting your efforts and resources into an “unknown path”.
On this article, I will clarify some questions about the VIPER workflow and if you should be using it on a new project – or even on your old running app.
Automated database migrations have been a convenient way of dealing with schema changes for a long time in Django. It’s been only 3 years since migrations have been incorporated into Django but South had been the de-facto solution since 2008.
The same way an ORM allows us to forget about SQL when writing queries to the database, migrations make sure we don’t write a single ‘ALTER TABLE’ in our schema changes. Some may argue that’s bad: we “lose control” over a critical part of our infrastructure, we don’t know how to write SQL anymore when needed, we’re not sure how that operation is really translated into SQL, etc, etc. Ok, these points are actually valid. However, Django migrations module is more than just a way of automatically generating and applying SQL statements, it’s also a transparent API to write your own database changes in Python. It comes with wheels for those who need it (or trust enough) and tools for those who like to get their hands dirty.
When I started as an iOS developer, my biggest problem was with app crashes, that’s because I really didn’t know how iOS, Swift, and Objective-C worked. Back then, I wrote a lot of bad code, not worrying about memory usage, memory access, ARC or GCD. That’s simply because I didn’t know about that stuff. I was a beginner, for God sakes.
Like most beginners, Stack Overflow community taught me a lot about “doing things the right way”. I’ve learned a lot of tricks that helped me improve my work process. In this article, I’ll share some of them about the most important tool used in this learning process: the breakpoints!
With a highly-competitive software development market, it’s becoming increasingly harder to find engineers to work along and develop great apps. In light of this issue, many startups and enterprises are turning to look at alternatives to hiring, being nearshoring one of the most common practices.
This post was originally written as an internal article on Cheesecake Labs’ wiki. It merges (no pun intended) pull request practices from many different cultures and backgrounds into a definitive workflow. We will discuss why you should have a guide for managing your PR lifecycle, as well as tips on how to accomplish that.