It isn’t easy to pick a technology for your new application idea. Everyone acts like the language they use is the best one out there (including us!). It’s hard for business owners to sift through the noise and figure out what tool is the right one for the job.
At Cheesecake Labs, we cut through the noise.
We’re clear about why we use Python — the benefits it brings to application development and the drawbacks too.
Do you have your next app idea fleshed out, designed and ready to go into development?
Now it’s time to figure out how you’re going to bring your app into the world, and here’s where some big questions around technology arise. Perhaps you’re clear on the frontend, but you are unsure which backend technology to use? There are countless programming languages and web frameworks out there — you can spend weeks looking at Flask vs. Django vs. Node.js comparisons and still not know which way to go.
$143 billion was spent in apps and on app stores during 2020 alone. And this wasn’t a fluke. Close to 90% of mobile internet time is now spent in apps — a number that’s been steadily growing in recent years.
So if you’re gearing up to develop an app for iOS or Android, you’re on the right track. Businesses that invest in these platforms are not only going to remain more competitive, they stand to boost their revenue and customer engagement as well.
With this guide we come to the third phase of the Cheesecake Labs’ four-phase Product Definition, Design, Development, and Optimization process. But in no way is the ‘Development’ phase the final step in any app’s journey.
After the Product Development phase is complete, you’ll have a fully functioning market-ready web or mobile app — something we can continue to work together on, gathering user feedback, exploring your problem-solving proposition, and staking your place among competitors. It’s a significant milestone in your application’s lifecycle (and one to be excited about). It opens doors to a new chapter, where you’ll be iterating and improving on a live product. Continue Reading
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.
Yes, you read it right. I took the liberty to adapt Daft Punk’s song title to talk about code review. As I write this, I’m wondering if it is going to pass the thorough examination of the chief editor, but I like how the title sounds (and it really describes how a Pull Request should be). And you see, even this harmless piece of text is going over a
rvesoin revision process before you can have the chance to be struck by my insights, so why shouldn’t we do the same with our code?
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.
In the past few years, websites have evolved into complex web applications, and what once was land of simple business informative pages, now is home to Facebook, Slack, Spotify and Netflix, changing the way you communicate, listen to music or watch movies. Front-end development has reached a new level and now requires more attention than it used to.
However, when an application grows considerably, a couple of issues start being more frequent than expected: you forget to update all places where a value is displayed in the UI, no events are bound to the content added by AJAX, just to name some — this list can be very long. These are signs that your code is not maintainable, especially when developing together with a team. Using a front-end framework provides a formal way to write collaborative code that you can read, write and update.