Joined 6 years ago
* 40 inch 21:9 aspect ratio. 34 is too small and 43 and above are too big
* QHD i.e. 3440 X 1440 resolution - why? Because it renders the programming fonts perfectly - many will complain about pixelation but for me it just seems perfect. This translates to a PPI of approx. 93 which is the same as for a 24 inch FHD monitor. Scaling spoils it for me
* Curve - not too less nor too aggressive - LG OLED is 800R which is way too much - on the other hand 2300R is too less - I think 1800 is ideal
* 60 Hz or more refresh rate
* Accurate color reproduction
* Matte finish / antiglare
Sadly, a curved monitor with the above specs does not exist. The only one as I mentioned is the LG OLED which has a far too aggressive a curve. There are some lesser known brands which come as flat which I currently use but I wish there was one that met all of the above.
On a side note, you will at some point in time have to deal with multi version workflows. I know that this is one feature that limits wide adoption of an orchestrator.
> The trend seems to be in the opposite direction. People became frustrated with the lack of types in Python and JavaScript, hence we get Python with typing and TypeScript.
Regarding typing, what I have tried to achieve is the best of both worlds. In unify-jdocs, we have the concept of typed document. This is a document that defines the structure of the JSON document. It defines what the "type" of a leaf node is i.e. integer, string etc. The validation / determination against this type is however done at runtime. This, I feel is acceptable because whenever we add a JSON path to a document, the first thing we would do is to test the read / write of that path. And any type mismatch would get caught there immediately. And so, from the point of view of being able to read / write / validate in a single line of code (even though dynamically) provides much simplicity and ease of use as compared to using POJOs. Plus we always know the exact JSON path we are dealing with.
Usually, I would prefer static typing but, in a scenario, where we can have hundreds of JSON document types (we deal with more than 500 in the same application), complex JSON document (ours go down more than ten levels deep with hundreds of JSON paths) and where the document structures may undergo change over project lifetime, the use of read / writing using a single line of code has many benefits. I shudder to think of hundreds (if not thousands) of POJO classes, the writing of accessor methods (null / empty handling, namespace etc.) and what it would take to refactor in the face of change. Just my opinion based on my experience in the past.
> I think you will find less traction with this method of posting to HN. People want a clickable link to look at the project
The clickable link to the repo / documentation is actually in the text (https://github.com/americanexpress/unify-jdocs). In the case of this post, I felt it more important for people to read the text rather than be directly pointed to the contents of the link and hence this approach.
