I read the article as promoting "let's use a simpler solution than that, and cut scope from the work to be done instead". If you are not willing to cut the scope of the problem to the absolute minimum, you are prioritizing something else over simplicity. That something else might be higher profits, ease of onboarding, keeping your boss(es) happy or even things like better error logging and observability. Most software projects, both for-profit and not, have a huge laundry list of things they have rightly prioritized over simplicity.
I don't even think the article tried to argue that it was wrong to want those other things over simplicity, just that most people out there only claim to want simplicity but then make another statement entirely with their actions.
I'm a BIG fan of my 13 mini. Bought it last December and absolutely love the small form factor. The battery is no problem at all, even with extensive use. I easily have 20% or more left at the end of the day and it's not even an issue when having it used for CarPlay.
I'm saddened by the idea there will never be a mini again.
What makes you think there will never be a mini again? Yeah Apple won't release a 14 mini from the rumors it seems but there is always a chance of another mini coming down the line a few models from now.
Safari user here. I often feel I'm a minority, but it's a really good browser for my Mac. Had been using Firefox after Chrome before switching to Safari.
What I find the real problem is not JIRA itself, but the fact that most of the time JIRA, is abused up to a point where it's become unusable. The inability or unwillingness (or both?) of the teams I've worked with to structure their work, write good user stories and keep things simple is in my experience the root cause of any shitty JIRA experience I've had. Of course it doesn't help per se that JIRA allows you to do that, but I guess that's not the tool's fault. (You can write bad and good essays with Microsoft Word).
Kut, meaning something like "fuck" or, more literally, "cunt", but in terms of offensiveness it's closer to the Australian context of "cunt" than the American context.
Here's the thing: Finding a solution to a problem, then making it into a business that is sustainable (read: had money influx) during dire times (read: economic recession), is a very good and healthy beginning for your start-up.
Doing startups when money is sloshing around, often leads to zombie companies that are on life support.
The panic in startupland stems from the fact that most of them are cut off from said life support.
I do. I develop lot of MVPs for clients and personal projects.
1. It is the fastest way to build. Auth, notifications, DB, cloud functions, analytics. You have everything you need.
2. Generous pricing. You will be able to get most of the things done with minimal costs on infra.
3. Dev Friendly: Anybody who comes with firebase alternatives, I always look at the toolset. If you look at Firebase, the CLI is amazing.
On top of this, I simply love their emulators. You can test everything before hitting production.
All in all, I simply love firebase. If they are able to get the cloud functions with go runtime it will be so nice. (Right now the option is to use Google cloud functions).
It is easy enough to connect from firebase functions to a cloudsql instance and the pricing is pretty good for the lowest tier (which is also easily scaled up). That said, might as well just use gcp cloud functions instead.
But what I really mean is that it would be cool to have Firebase db access SDKs and realtime capabilities, with a relational, non-proprietary database. If you plug in your CloudSQL or another managed database you don't get that, and have to write everything on your own.
Supabase seems to be going in this direction, and while I haven't tried them yet, I certainly see how it's an attractive proposition.
I do. If I were to attend a hackathon (which I haven't since 2020), I would use Firebase. It's simple and they sponsor every hackathon I've been to, so I get free credits.
That said, if I attend today and ignore sponsorships, I'd actually get DigitalOcean market place deployment of Appwrite. I honestly think it's quicker to get started with, and I like owning my data ;)
I had a couple of side projects running on Firebase until I discovered the open source alternatives. I can self-host on a $10 droplet which makes the costs very predictable
Appologies, it was not my intent to make a joke, more to acertain how people became aware of the condition Lupus of which myself and it seems, many others awareness was born from that TV show.
But you would not be destroying data. It's an UI interaction which you're applying (i.e. closing the modal view, and thus navigating back to the previous state of your UI).
I agree with you that modals are abused. Modals should - in my opinion - be used for immediate actions such as your example.
Side panels however are fine in my book. In the end, we're talking about the same thing: example.com/fruits/new - Navigating (there you have it) to this URL should provide the user with an interface to fill out a form to create a new fruit.
In practice this could just as easily be a side panel triggered from the fruits list page, by clicking on the "new fruit" link. The URL should reflect that UI state change.
