paleite

Is it using the Barcode Detection API for browsers that support it natively?

https://developer.mozilla.org/en-US/docs/Web/API/Barcode_Det...

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.

It copies lots of code => copy-lot => copilot

I guess that means I feel the level of expectation is in the name.

Couldn’t agree more!

Explain the differences in the following to a new developer:

something - a regular variable

$something - just another regular variable with a fancy char

#something - now that’s a private variable

!something - this is… uhm… a regular variable cast to… eh… boolean, then inverted…

~something - type cast blah blah bit flipping magic

!!something - same as !something except inverted again, because using Boolean(something) is not 1337

//something - a comment

Yeah… personally, I much prefer the more explicit ways to write code. it’s cryptic enough as it is, why make it harder for your peers

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.

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.

TypeScript/JavaScript with VSCode and Chrome.

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

I think Charisma on Command nailed it in their video: https://youtu.be/cHyYlFCaXPM

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.

”But everyone else is going to” *Citation needed

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/

Ever since I read an article about them posted on HN, I can never unsee them

The eBay-listing apparently was for non-PAL carts, so no luck. :(

The SID chip uses subtractive synthesis, whereas this synth uses frequency modulation. They are very different and as such it's very hard to get the FM synth to sound close to the SID chip.

How about a clip?

He's actually already won. The original URL included www., the current one doesn't anymore.

Look ma, I made an Alanis Morissette cover: http://imgur.com/zVZNJnm

It's likely that's a remnant from Normalize.css (where each hack is assigned a number and an explanation) that didn't get removed when uglifying the CSS.