181–190 of 316 posts
Writing GUI apps for Apple products. Too many variables to mention, but I wrote my first Apple application in 1986. It took several weeks, and wasn't much to look at. These days, I can spin out a full-fat, shippable app, in a couple of hours. I do that all the time, for my test harnesses.
The general theme of this list is that technology gives us more and more hoops to jump through, then provides some trampoline to jump through them. We're supposed to be eternally grateful. I'm not. I want to focus on problem-solving, not masterfully using trampolines. > SSL certificates, with Let’s Encrypt Semi-mandatory SSL certificates weren't a thing on the web until fairly recently. Not managing them at all was c…
I've been on teams that haven't used docker for dev envs and teams that do in the last 5~ years. The teams that used docker were significantly more productive since each dev env was a replica and forced the team to maintain a common env. The dev env drift without it is huge and causes so many "it works on my machine". I can see a one man show or maybe two not needing a docker dev env but any sizable team IMO it is ab…
By default, Docker runs everything as root. This isn't a huge problem on macOS or Windows, where Docker runs in a VM and there's some sort of UID mapper mediating things. If a file is generated from a process within Docker (e.g., temporary or log files) and you're running in Linux, now you have files in your local system that you can't edit without "sudo". Fine, don't run the container as root. I'd have expected that to be a best practice, but it doesn't come up in Docker's best practices guide [0]. Adding our own user and switching to that isn't a huge hurdle, although this didn't seem to be an area that we'd have to chart our own path. Unfortunately, some 3rd party images don't run particularly well, if at all, if not run as root.
Once we got that running, we hit our next issue. Although things were working well for one developer, they broke for another because there still existed the same basic problem with Linux users ending up with files owned by UIDs other than their local account. It turns out that not every dev is running with the same UID. Okay, so now we need to map the UID and GID at image build time, but that might break things for people on macOS.
All of our Dockerfiles ended up with something like:
ARG app_user_uid=61000
ARG app_user_gid=61000
ENV APP_USER="app"
RUN groupadd -g $app_user_gid -o $APP_USER
RUN useradd --no-log-init --create-home --shell /bin/false --gid $app_user_gid --uid $app_user_uid -o $APP_USER
docker-compose build --build-arg app_user_uid=$(id -u) --build-arg app_user_gid=$(id -g) ...
docker-compose build ...
I would also add something along the lines of "building big webapps". Large frontend codebases used to be scary Lovecraftian horror where things were only touched out of utmost necessity. Runtime errors for weird corner cases. Dangling dependencies that no one could figure out whether they're safe to update/remove or not. Refactoring was both an art and an arcane incantation at the same time. Modern tooling and best…
You can definitely taste it if you pay attention, like "yep, that's it, it's that vomit aftertaste."
Writing GUI apps for Apple products. Too many variables to mention, but I wrote my first Apple application in 1986. It took several weeks, and wasn't much to look at. These days, I can spin out a full-fat, shippable app, in a couple of hours. I do that all the time, for my test harnesses.
I would extend this to GUI apps for every system. Even GTK apps on Linux have gotten there.
Writing GUI apps for Apple products. Too many variables to mention, but I wrote my first Apple application in 1986. It took several weeks, and wasn't much to look at. These days, I can spin out a full-fat, shippable app, in a couple of hours. I do that all the time, for my test harnesses.
I would extend this to GUI apps for every system. Even GTK apps on Linux have gotten there.
Too many options (flatpak, apt, rpm, appimage, snap). No simple "please turn this directory tree in to a package" options. Dependency hell due to lack of binary compatibility (and no simple way of putting DLLs in the app directory like on Windows or in the dpkg like on macOS).
As someone who leans frontend, I find firebase and serverless (somebody else’s server) solutions really powerful for prototyping an idea or building a proof of concept. You can get something in front of your users tomorrow. I would second guess SaaS startups that start by building the infra/data models unless they’re going for a highly technical play (aerospace, hardware, etc) or already have a ton of market knowledg…
Agree with starting focusing on UI first. But haven’t seen a speed advantage at this stage of serverless vs a simple monolithic backend app with a bunch of endpoints. You can get something in front of users within hours. Either way allows you to overengineer and focus on the wrong thing.
I would love to see the reverse of this 'things that used to be easy and are now hard' That would be an interesting read
(Not saying these are bad things! Just annoyances I've run into during development.)
Earlier quoted context omitted.
It works for pure Rust code but once you bring in C, you need another tool chain too. Same as Go, as far as I know. Zig has both beat right now, as you do not need anything else in either case.
Oh, my bad, now that I think about it, all my Rust projects have -sys dependencies so I somehow assumed a cross toolchain is always required.