I would expect not, as that API does not currently support iOS (which is a real shame). What's annoying is that iOS bundles an excellent barcode scanning framework in Vision, so it wouldn't be tremendously difficult to add to safari.
Hi! No it does not use the Barcode Detection API, as that is not widely supported, and the last time I tried it (which is admittedly a while ago) performance did not seem great.
i think that’s what people’s argument FOR tailwind is:
CSS can easily be a footgun, unless everyone on the team uses a sane DOM structure, CSS variables and well thought out CSS selectors.
i’ve yet to witness a project without “!important” scattered throughout the codebase.
Exactly this. Anyone who has worked with a junior developer understands this intuitively. They spend a week smashing their head against the desk figuring something out, then in review, you (the senior dev) can look at it for 30 seconds and see all the holes they missed and think of a simpler solution that uses 1/3 the amount of code.
Simplicity is a skill and it's hard to do. There's a reason most people are not minimalists despite the almost universal western desire to "have less stuff".
I mean the following as feedback to help you find more users, not as critique; I understand where you’re coming from and this is just how I would personally approach it:
What I immediately noticed looking at the README, is that the communication is centered around you and your values, rather than on the end-user:
You mention why you created it, not what it enables the user to do.
You use Linux-lingo, like “free (speech and beer)” which many users are unfamiliar with and don’t know why they should care.
Your installation instructions make it hard for users to pick which one they should choose.
There are no Mac binaries, but Macs are wide-spread among developers.
Windows binaries mention “x64”, which is very technical and might scare users away.
The Ubuntu screenshots make it look like “Linux only”. You could replace it with a Windows or Mac screenshot, to get people to understand it works on their platform.
You could still keep this technical (and potentially alienating) language in your documentation, but simplifying the README to make it easier for the 90% of your potential audience could make it more popular.
You mentioned in this thread that some people don’t want Electron. That’s true, and it’s a great USP for those that require it, but personally I would avoid assuming that it’s the USP that convinces the masses.
Thanks for the feedback! I can certainly try to improve the structure of the README, though I'm not sure if I agree with some of your points about giving more priority to non-Linux users. The thing is, at least in my eyes, Gtk generally feels terrible on platforms where it is not native (I would in fact even avoid using it in a Qt-based Linux desktop setup, just as I avoid Qt-based applications as far as possible in my Gtk-based one), and at any rate the ports are often lacking even in features (for instance, last I checked, Windows Gtk would not allow me to read tablet pressure information). If you are using Windows, and don't care for "free (speech and beer)", why would you even want to use anything other than OneNote? I'm somewhat wary of repeating the mistakes of Firefox (and GNOME) of snubbing a likely target demographic to court an unlikely one.
(Regarding Mac, I unfortunately don't have a Mac and neither does anyone who I know well enough to ask to borrow theirs, though someone did in fact contribute homebrew-based build scripts that supposedly work at some point. I just have no idea how to package the result to make it easy to install.)
- You don't want to give more priority to non-Linux users
- GTK feels terrible on those other platforms
- You don't believe those who care about licensing issues would use it
- You cannot build releases or installers for Mac
The first thing that comes to mind on reading your response is that the non-Linux users are a market you are not really interested in - and even if they were they are not a market you can effectively serve (installers, updates, issues).
You should consider formally abandoning official support for non-Linux, as in reality you don't currently have actual support for them anyway. Be honest, cut your losses, and choose your customers. Cross-platform is not a benefit if it is unsustainable.
Well, it's not exactly unsustainable - the Github CI continues producing those builds without me having to do anything for it (it in fact didn't break even once in the past year, compared to several breakages on the "backwards-compatible" Ubuntu 18.04 deb which happened whenever Github changed something about the package bundle available to that image). If someone reports a bug on Windows, I will look into it, and/or spend some time walking them through a workaround (since I do in fact have access to Windows setups). As I see it, in the most natural sense of support, I do have support for Windows, even though it is what I guess you would call Tier 2 support.
To nitpick a little, I also didn't say I don't think that those who care about licensing issues would use [the Windows build]; rather, I think that those who don't care about licensing issues and are on Windows would not use it, because there is a Windows-only product that is closed-source which I am unlikely to be able to compete with on that ground.
> The Ubuntu screenshots make it look like “Linux only”. You could replace it with a Windows or Mac screenshot, to get people to understand it works on their platform.
Replace? I'm not Linux user but this sounds strange to me. He did native GTK app and he should not be considering Linux users?
If you tell me a programmer wrote a thing in a month, and another programmer wrote a similar thing in a year, I'd assume nothing about either, because there’s too many parameters at play.
If a project took only 1 month, I’d be very cautious with calling it easier to work with, because it likely means fewer tests (leading to lower velocity long-term) and fewer hours spent by other developers trying to understand it, and giving feedback on how to improve legibility.
Creating something quickly can be really important in specific contexts, but actually KEEPING something flexible to work with, hard to break, and easy to understand is more important when dealing with software that’s supposed to last over many developers and a long period of time.
Maintaining velocity requires you to spend more time on keeping the code base healthy.
I find the notion of being a fast programmer irrelevant in a business-context. Because there I think it’s more valuable to be a programmer that can ensure business goals are met on time, ensuring the correct problems are solved, ensuring contracts aren’t broken, while still keeping the code base professional (i.e. well-tested, clean, consistent).
Being a fast programmer is great and all, but being reliable is the more favorable trait if I had to pick one. Both require huge amounts of active training.
I find JavaScript to be very accessible, because it can be run in the browser. No extra tools required and if you want, you can get immediate visual feedback by, for example, manipulating the DOM
The biggest takeaway for me was: make the interviewee feel comfortable by letting them talk freely about subjects they feel passionate about, and the interviewer should ask genuine and good questions by properly researching the interviewee beforehand.
While technically not OEM SNES, the 8bitdo repros are of extremely high quality and if you get a matching retro receiver, you can use them with the original SNES hardware (and wirelessly): http://www.8bitdo.com/snes30-sfc30/
https://developer.mozilla.org/en-US/docs/Web/API/Barcode_Det...