> Surely we can agree that distributing shared libraries via a package manager is a good practice, no?
At one point, long ago, you could just download a file, reference it in your index.html, and use it without ever having to worry about updating this package. It had its flaws, but it also had many advantages compared to having an external dependency that might conflict with your version of Typescript, or being highjacked by bad actors.
I don't diss the concept of package managers at all, but there are lots of case where vendoring an external package is preferable than adding it as a dependency.
Agree, and the most maddening thing is that the platform is honestly better than ever. Doing your layout in CSS is so much easier now than it was 10 years ago, thanks to CSS variable, containers queries, and widely supported flexbox & grid.
It's the NPM ecosystem above that's being stupid, and believe that adding more tools and more processing is a good thing.
While this case makes for a pretty fun story, there's other case of 'fake' event posted on social media with more sinister reasons behind it, like when russian troll farm used social media to try to organize protest that were bound to devolve into riots [1].
This article is a joke, but a joke cruelly missed by it's own author.
Point in case: holding 'enterprise programming' as a paragon of software craftsmanship.
A realization I've had, seeing true 'enterprise programming' at work, is that most of the time processes acts like pass-band filters for quality: on the lower side some sort of garbage is avoided by adherence to processes, and on the upper side true software excellence is made impossible, or at least way harder than it ought to be.
A few examples:
- A simple CRUD app got a less-than-ideal data-flow, with routing and data-passing between pages were treated as an afterthought. The reason? The (Scrum) process-heavy organization understood work solely as defined through JIRA tickets, and they naturally created 1 JIRA ticket per page and per component, and of course heavily parallelized the work between many coders. As a result, each page matched the specs, but the overall data architecture fell through the cracks.
- We had one member of a previous team who alternated between 'okay' to '-1x coder'. His main issue is that he didn't really thought about the impact of his code, he just kinda appeased the gods of linting until they were quiets. The issue is that it was often just breaking stuff, or straight up putting deceitful typing in a way that would have spread in the applications. Automatic checks were all in the green, but everything was subtly wrong.
- Over-engineered types in Typescript. Some (usually junior) ambitious programmers see the power of types, and dream of creating types so perfect that the whole program will be created just by pressing 'tab' at the end. It sometimes work, but it also often create ungodly monstrosity where a KISS approach would have been less painful. We've all went through this stage, but some people just saw "The sorcerer's apprentice" section of the 1940 Disney movie 'Fantasia' and then stopped midway, too busy automating everything.
- Over-reliance on outside library, and a organizational incapability of creating anything remotely custom. Yes you should avoid reinventing the wheels, but if your job is also to make wheels, and none of the ready-made wheels fits the situation, then you better be making wheels sometimes.
- Over-reliance on fads and marketing. Process-heavy environments penalize individual initiatives. As a result, the "way everybody do something" becomes the only possible way, and this is very susceptible to fads and content marketing. And your soul dies a little when you cannot stop the "Sure, Redux seems very heavy for the needs of this project, but Redux is very powerful! That's why it's in every project!".
In general, processes and systems attracts 'system people'. They can be useful, but too much will just create a dogmatic, un-pragmatic work environment where business consideration are swept under the room.
very good examples pretty much every one I've come across, the over-engineered types one (add python typing to the list too) feels pretty spot-on and common
But it's a camera app. Of course it needs the camera.
It's not overreaching app permission, it's been rejected because the text "The camera will be used to take photographs" wasn't considered a good enough explanation for the permission.
If you cant sufficiently explain why your app needs the permissions it does thats on you and the submitter needs to take accountability here. Resubmit with a better explanation.
I get that the app store is strict. But its strict for a reason. Apple or the app store isn't out to get your app or you.
All right, mister smarty pants. Let's hear it then: What is a better explanation than "this app need camera permissions, because it takes photos, because it is a fucking camera app"?
Halide is a professional-grade camera application that offers advanced photography features such as manual controls, RAW and ProRAW capture, live histograms, focus peaking, depth capture, macro photography, augmented reality overlays, adaptive gesture controls, exposure tools like zebra stripes, and advanced video recording options. In order to provide these functionalities, these require camera permissions to access and control the device's camera hardware in real-time. Each feature relies on direct interaction with the camera to adjust settings, analyze live image data, and offer immediate feedback, making camera access essential for the app to function as intended and enhance the overall user experience.
moral of the story. spend 3 extra minutes writing something out and save yourself from a headache.
why are we assuming every person that reviews apps knows what ur app does? with submissions like this the explain it like im 5 approach is necessary.
I agree that permission requests should include sufficient context -- but I think that paragraph is way too long for the purpose. People do not read unexpected dialog text. I'd save that for the App Store description, when people are more receptive to detail.
For the permission request, I'd condense your paragraph into a sentence or two.
It's not unusual to download an app, but not launch it immediately. Demanding that the user remember your App Store description is unfair. It's your baby, not theirs.
They might not launch your app for hours or days after downloading. And Apple, reasonably I think, wants developers to try harder to accommodate user's realities.
There's strict, and there's kafkaian. It's not as if the reason why a camera app would require the camera is pretty obscure, especially if neither the app nor the permission text changed that much between reviews.
Same. I felt that the article generally got his point across, and kept a good balance between "straight to the point" and flavor text.
And while I don't want profanity present in all the articles I want to read, I find this kind of tone way more appealing than the dry, PR-approved blog posts where the only kind of levity found are "2010 internet humor" cat pictures, and "Corporate Memphis" illustrations.
While not a wrong response in itself, the onboarding cost argument tend to be a bit exaggerated most of the time, because unless you plan on hiring people for a week at most, you're usually better served by avoiding sources of complexity.
The argument is to avoid going all-in on Redux by default if you're doing a React project, not telling you to hand-roll your own Redux.
If you're doing a mostly-static site with a few bells and whistles, then HTML and plain old JS will probably do.
> “The merchants of complexity will try to convince you that you can’t do anything yourself these days,” wrote David Heinemeier Hansson (DHH), the creator of Ruby on Rails. “You can’t do auth, you can’t do scale, you can’t run a database, you can’t connect a computer to the internet. You’re a helpless peon who should just buy their wares. No. Reject.”
Such a beautiful quote, and really describe well my experience. For the past few months I've been in a team that keeps trying to pull dependencies and library of components for the simplest of things, and trying to argue my point kinda in vain, to the point that I'm starting to get cranky and rant-y about the subject[1].
Need a header on top of our application? Let's use a Angular Material component, why would you code it yourself? Need to display stuff in a grid, oh we better should center our project around Ionic so we can use ion-grid.
More than 'merchant of complexity', I thing that a huge culprit is the need for content marketing, and so any new thing in a framework become the theme of multiple conference, and the obligatory Medium posts explaining the new stuff (in itself, not necessarily a bad thing), but which often tend to snowball into "Method X is obsolete, why you should all port your code using newfangled method Y".
And now, I have a colleague working in an Angular app that keeps on rewriting stuff and wrap everything with signals. Signals can be good sometime, I'm not against angular signals in itself, but he's just taking dead-simple code and making it more complicated because apparently now everything Angular should be about signal. At least I'm away from the part of the React ecosystem that keeps trying to re-invent the cascading part of CSS but with Typescript in the mix. shudders.
At one point, long ago, you could just download a file, reference it in your index.html, and use it without ever having to worry about updating this package. It had its flaws, but it also had many advantages compared to having an external dependency that might conflict with your version of Typescript, or being highjacked by bad actors.
I don't diss the concept of package managers at all, but there are lots of case where vendoring an external package is preferable than adding it as a dependency.