HN user

agarv

28 karma

Front-end and full-stack web developer in NYC area

allengarvey.com

github.com/allen-garvey

Posts2
Comments20
View on HN

Color dithering is very similar black and white dithering, the difference is that instead of 2 colors (black and white), you have n colors, and you want to find the one that has the shortest distance to the current pixel. There are various formulas[1] to determine which color is closest, and which formula you choose will have an effect on the results. I built a dithering app[2] that lets you choose the distance formula, so you can see for yourself.

[1] https://en.wikipedia.org/wiki/Color_difference [2] https://dithermark.com

It's not a phone app, but I made a web app[1] that can get pretty close[2]. From looking at the images I think the reason why other other apps don't look the same is that they try to emulate it use an ordered dither, while it looks like the Gameboy camera is either adding some randomness or noise as well. I have a Bayer (R) algorithm that adds randomness and it seems to get closer to the Gameboy camera output.

[1]https://app.dithermark.com/ [2]https://imgur.com/a/AiQa14B

Something that I don't see mentioned is that this emoji opens the door to accidental racism because you are assuming the other person's race when you use it, since presumably one of the hands belongs to the person you are speaking to. This contrasts with something like the thumbs up emoji, where it is meant to represent your own hand, and so you can make it any color you want. It is also not clear if you use it, which hand is supposed to be yours- I am the hand on the left or the hand on the right?

Disclaimer: I am not a professional photographer nor formally studied photography, and have never used a DSLR, but I have been using mirrorless cameras (Sony NEX series) since 2011.

While there are generally less "native" camera lenses for mirrorless systems, one less well known/publicized advantage of using them is that you can use film camera lenses. While you do not get autofocus and there might be vignetting at the corners (which I personally like anyway), you can get a good quality lens for a good price by doing this. It also can be cool if you are trying to recreate a "vintage" look, or just going for something weird or unusual. All that is required is a cheap adapter that you costs around $5 on ebay. Two of my personal favorite lenses to use are the Jupiter 9 (the whole Jupiter series are Soviet copies of Carl Zeiss lenses) that I got for $175, and the SLR magic 3517E which I got for $37. This video has a general overview: https://www.youtube.com/watch?v=aQLi4g-wyDA

While there can be UX benefits to using SPAs, something I have not often seen expressed, but which I believe is that the main advantages of SPAs are for business rather than technical reasons.

1. Clear separation of concerns for front-end and back-end teams. With SPAs, the work is clearly divided into front-end and back-end parts, with the back-end team working on the server side code and the front-end team working on the static assets (HTML, JS, CSS). Both sides only communicate through a clearly defined API (e.g. REST, GraphQL, SOAP) which allows both teams to work independently of each other, and means that if there are bugs or problems, there is less confusion on which team is causing them and thus which team needs to fix them. Compare that with server side rendering using an MVC framework such as Rails. The migration and model code "obviously" belongs to the back-end team, and the static assets (JS, CSS) and views/templates belong to the front-end team, but what about the controllers and routing? Both teams are going to need to work on those parts of the codebase, and that's going to increase the need for inter-team communication and confusion on which team owns what. For example, I interviewed at a company where the front-end team was US based and the back-end team was outsourced to India, and they were moving to a SPA so the teams could work more independently. Previously they had used JSP, which meant the front-end team had to write HTML and then send it to the back-end team and then they had to coordinate how the back-end team was going to re-write the HTML as a JSP template.

2. Cheaper mobile and desktop apps. While it seems HN is very negative about non-native apps, it's not hard to see the business case of quickly and cheaply converting your website into a mobile or desktop app using something like Electron, Cordova or a web view. Even if you do plan to make a native app, the SPA and native app can reuse the same APIs, reducing the amount of work for your back-end and QA teams.

3. Flexibility in changing back-ends. While less common than the other two cases, if you decide to change your back-end code (such as Twitter moving from Ruby to Scala) if your app is an SPA you only need to recreate the APIs and don't have to rewrite all your templating code (this is less of a problem if you use a more "neutral" cross-platform template language like Handlebars). For me personally, I'm moving all my personal projects to Elixir/Phoenix from PHP, Rails or Java, and because I used server side rendering I had to convert all my templating code to EEX.