Cheesecake Labs 2019 Highlights
with 
adminPosted on
adminPosted on 
Insights about the app design and development ecosystem.
adminPosted on
Antonio DuartePosted on As an NFL fan, MVP has different meanings for me on weekends and business days. Without diving into the curiosity, today I’ll talk about the latter, starting with some general analogies and moving further with specifics on the mobile & web app design and development lifecycle. So let’s get started.
Iacami GevaerdPosted on Browsers are a complex piece of software: inside a web browser there are features comparable to a whole operating system. Every time I googled how to make a web browser, the answers were quite shallow, usually talking about how to consume some browser engine and make something on top of it. This article aims to walk through the whole process of making a web browser. On part 1, I’m going to talk about specifications.
Jonatas BaldinPosted on Onboarding new developers in a project is always nice: they bring new ideas, different expertises and outside-the box thoughts. They tend to tackle problems and create solutions in a creative way, adding even more enthusiasm to the team. But before getting down to code, they need to set up their own development environment, which can easily become a headache.
Installing a local database, compiling the right program language version and solving library dependencies – possibly across different operating systems – are a few tasks inside this challenge.
Today I’ll introduce to you Docker and Compose – a container platform and its simple configuration tool – to help your team get up and running as fast as possible. Continue Reading
Bruno MüllerPosted on Smartphones have been in the market for a while now. After some comings and goings of different players, Android and iOS were established as the main contenders and now represent almost 99% of the global market share. Because of that, virtually any new app idea will focus on these two platforms.
In this article I’ll be talking about the main differences and similarities that every designer should consider when designing UX and UI for iOS and Android. You can be starting from scratch or already have a published app that needs to be adapted for the other platform. For both cases, I’ll be constantly linking the platform guidelines, as they are the main source of reference when designing a new interface.
Bernardo SmaniottoPosted on Hybrid technologies have been employed for quite a while in mobile application development. Frameworks such as PhoneGap and Ionic come with an appealing motto: Develop once, run everywhere. And they actually do what they promise: you write a web-based app once and release it everywhere, from iOS to Android and the Gates of Mordor, as long as it gives support.
I do believe that they play an important role in the mobile app development scene: the huge community of web developers can write mobile app code and are able to deploy fast. But, in my opinion, the idea of developing one shared application for all platforms is dead per se.
That’s where React Native lands. It has a slightly different motto: Learn once, write everywhere. It might seem the same but with a closer look, you’ll spot the difference: it’s still JavaScript code, but with a dedicated one for each platform. And that changes everything. Each platform has its peculiarities and user expectations vary from one to another.
Bruno GueriosPosted on As an iOS developer working at a startup focused in collaborative development, I’ve been involved in several projects so far, and most of them share common tasks such as downloading and caching images, performing network requests, and building Auto Layout views.
At first, I had a flow that I thought was good enough to accomplish these basic tasks (or any other, for that matter):
That seemed like a good flow at first, but got a bit tiresome in the long run – after all, nobody likes to hack for a living.
Alex CordeiroPosted on Let’s face it: developing scalable front-end code isn’t piece of cake. No matter how well-structured the framework/architecture you’re using is, everything will be converted to ye olde HTML, CSS and (vanilla) JS.
Well, the good news is the open-source community already created solid frameworks (like AngularJS and ReactJS) to make your life incredibly easier, so you can work on high-level code and nevermind the hardcore stuff.
This brings up a new scenario, though – after getting used to building things the old-fashioned way (or not-so-old-fashioned, with tools like Backbone.js or Ember.js), you’ve decided to try what is trending on front-end development now: ReactJS, using the Redux architecture. You got excited with the possibilities this opens (and – oh my! – the ability to ditch jQuery once and for all), and, after working for a few weeks you realize that your code is a total mess.
Bruno MüllerPosted on If you’re either a UI designer or a developer, you’ve probably heard of Sketch in the past years – or maybe you’re even using it. Sketch has become a very popular software and broadly used by UI designers. In this article, I’ll show some steps of my workflow when creating and exporting assets to mobile or web applications.
I hope that this article will be useful for designers starting to use Sketch or developers who need to export assets from a Sketch file. If you’re already experienced with Sketch, you’ll probably be familiar with most of the things I’ll be presenting, but you can still get some good insights from this article.
Thiago VictorinoPosted on A common way to describe a product development process is with the Design – Front-end – Back-end stack. This approach takes into account the disciplines involved on the process, and though it helps making things understandable, the distinction enforces the idea that the process is linear and phase-dependent.
This linear flow can also be defined as the waterfall model, and it’s rather common in the web industry. All pages are designed upfront, then a set of mockups are handed off to be translated into front-end code, and then, after all of that, the back-end logic is created. This causes an isolation of professionals on each phase, which leads to a series of implementation issues, mostly due to the difficulty of foreseeing all details and use cases on the early stages.
It also leads to the notion that there’s “my work” and “your work”. It’s not rare to hear developers saying: “Designers can’t touch my code!” or designers complaining that “The front-end developer messed up my layout!”. This creates barriers to the process. As obvious as it might sound, everyone is working towards the same goal: building outstanding products. And a more collaborative process is the way to achieve that.
