deepakarora3

I one hundred percent support the above. Jooby is a great performant framework, simple to use with tons of flexibility and features. Super happy with it!

I would say yes. Having been a big fan of Dell and having used it's laptops for both professional and personal uses over many years, I have moved off it to Acer. Couple of reasons - the first is that there is a price premium which I cannot seem to justify and second is the teething / niggling issues which I have had to face in pretty much every Dell I have owned. Sometime, it will be too long a time to wake up from sleep or a random crash which requires me to fetch bitlocker key from my account so that I can boot it up again to driver update issues to the fan continuously running for no reason etc. I had, by chance, a good experience with Acer in the past and since then have purchased a couple fo them more and the experience has been seamless and pleasant. I do hope Dell ups its game as it was an iconic and innovative brand but there is less now to differentiate it from competition and so no reason for the premium to be charged.

What skillset and expereince do you have which is in demand? Just curious to know.

For me:

* 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.

I see that you gave the person 5 warnings - I feel 3 times is less and this is exactly what I would do. Its so much better to give people more chances rather than less and then letting them go instead of letting an ego or something similar come in detween earlier.

If you are using Java, you may want to check out the library I created for American Express and open sourced, unify-jdocs - it provides for working with JSON documents outside of POJOLand. For validations, it also has the concept of "typed" document using which you can create a document structure against which all read / writes will be validated. Far simpler and in my opinion as powerful as JSONSchema. https://github.com/americanexpress/unify-jdocs.

There is a diff functionality which I have provided in unify-jdocs that I think does exactly what you are looking for. You can get the details here -> https://github.com/americanexpress/unify-jdocs. At present it is only for Java. And if you do take a look, please feel free to give feedback - thanks.

JSONPath is good when it comes to querying large JSON documents. But in my opinion, more than this is the need to simplify reading and writing from JSON documents. We use POJOs / model classes which can become a chore for large JSON documents. While it is possible to read paths, I had not seen any tool using which we could read and write JSON paths in a document without using POJOs. And so I wrote unify-jdocs - read and write any JSON path with a single line of code without ever using POJOs. And also use model documents to replace JSONSchema. You can find this library here -> https://github.com/americanexpress/unify-jdocs.

I have been using Google search for many years now and for the past few years have been wondering if the search has really gone bad or is it just me. I remember the days when searching for something used to bring up a few sponsored links separately and I could go page after page with different results on each page allowing me to access a wealth of information and extending my reach deep into the internet. Now, it is all sponsored links and the same ones page after page. It is so sad to see and the worse part is that I am not seeing any alternative. Bing is equally bad, DDG only marginally better. I hope there comes an alternative soon but I also realize coming into this space is certainly not easy.

I went the other way - because I so much disliked working with DTOs to work with JSON, I wrote a library that allows you to get rid of DTOs in the first place. No more POJO / DTO in order to work with JSON data and much more. You could take a look at https://github.com/americanexpress/unify-jdocs. I think you will find it interesting!

Nice. It is great to see native lightweight opensource (I hope it is considering that someone said that there is no license file yet) solutions hit this space. For what it's worth, I have built something similar to this but for Java programming language. You can find it here -> https://github.com/americanexpress/unify-flowret. My reason for building something like this was that the product market is just too unwieldy to work with and has multiple layers of complexity which most of the time can be done away with. Just my opinion.

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.

"And that’s when a real problem emerged; nobody knew who I was" and "I felt invisible, like I was all alone in this world. I could have had the best thing in the world, and no one would care": Could not agree with you more on this - over the past many years it has been more and more important to build a digital brand for yourself and have many followers - to be networked with people and know people who can provide you with reach - something which is difficult for introverts and challenging to do now since I have crossed 50. I personally have felt this helplessness in trying to promote a couple of opensource Java libraries I released on behalf of my employer (shameless plug here -> https://github.com/americanexpress/unify-jdocs and https://github.com/americanexpress/unify-flowret). I thought I had done something of value which would be readily adopted by people after they saw it - guess what - first I have not been able to get through to a wide audience and second - I underestimated what it takes to get people out of their comfort zone and their traditional thinking. It is so difficult for people to accept that there may be better ways of doing things once they get used to a certain way. Anyway, I don't think you failed - you learnt and it is never too late to learn and do something new. Something will click eventually and I wish you all the very best.

Auther here - thanks for responding! I really do appreciate it.

> 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.

Nice work! I see that that this is for processing / parsing large data sets and where documents do not conform to a fixed structure and for Go language.

I made something similar in Java - unify-jdocs - https://github.com/americanexpress/unify-jdocs - though this is not for parsing - it is more for reading and writing when the structure of the document is known - read and write any JSONPath in one line of code and use model documents to define the structure of the data document (instead of using JSONSchema which I found very unwieldy to use) - no POJOs or model classes - along with many other features. Posting here as the topic is relevant and it may help people in the Java world. We have used it intensively within Amex for a very large complex project and it has worked great for us.

Nice! Talking of JSON schemas and validating JSON documents against schemas, for Java, I wrote unify-jdocs where I do not use JSON schemas but still do validations (I found them unwieldy to use and was looking for something simpler). You can find details here -> https://github.com/americanexpress/unify-jdocs. Also, no POJOs / model classes, just reading and writing JSON paths in a single line of code. It's helped us tremendously in managing complexity in a very large internal project. I am hoping it helps others.

A similar experience occurs with me almost always when jet lagged. After fighting off sleep for much of the day when I finally fall asleep during the later part of the day, it starts off exactly like described - a really dreamy state. Then after I have slept a couple of hours, I enter a state where I am sleeping and also awake at the same time and wanting to wake up but in a state of sleep paralysis where it is a herculean effort to try and shake off sleep and wake up. More often than not, even though I know I am in this state, still a panic sets in me that I am not able to shake off sleep and I wake up after quite some effort. And yes, I have had dreams where I have been able to solve some problems at work even without thinking about them during the day. Its totally fascinating!

Not at all to be critical of JSON schema, but my experience has been that for most use cases it is an overkill. As simple as it may be, it still is relatively complex. As someone mentioned in a prior post, if the validation fails then what? Even though the JSON schema document is human readable, just by looking at the JSON schema document, its not intuitive to visualize where the particular path resides in the actual document. And one would need tools written on top of JSON schema to be able to do operations like merge one JSON document into another while validating at the same time. To make things simple, I had created JDocs. What this allows is to write the JSON schema in exactly the same structure as the JSON data document, just that the value field contains the validation specifications. Of course it does not have all the advanced features of JSON Schema (like some properties and cross referencing abilities), but then as I said, it meets our requirements in a real straightforward and simple way and opens up multiple possibilities in manipulating JSON data. You can read about it here. I would welcome feedback and apologies if you feel it is off track. Thanks.

https://github.com/americanexpress/unify-jdocs

Yes it does but as someone else mentioned, it can be really challenging to work with. Its difficult to visualize the structure of the document. Its difficult to program against. This was one of the problems which I wanted to solve when I created unify-jdocs. Agreed that it may not do all the things that JSON schema does but it does all those which are required 90% of the time. Along with other things like not having to generate any model classes (code generation) and being able to read and write any path in a single line of code. And being able to merge JSON documents into another. Strong typing has its pros and cons. In my opinion, for complex JSON documents, going the strongly typed way makes making change difficult in the long run. Think of JSON documents the size of 3000 JSON paths going 10 levels deep etc. You can read more about this Java library at https://github.com/americanexpress/unify-jdocs.

Creating Java object models to map the JSON documents into was the problem that I was really fed up of. In my work, we have hundreds of JSON documents to manage and many a time the structure of the JSON document also changes. Managing the JSON object model classes in Java is all boiler plate which adds very limited value in my opinion. To solve this, I wrote unify-jdocs. You can completely eliminate the use of domain specific object model classes and work directly on the JSON document (an intermediate construct similar to what the author is pointing to). You can read more about it here at https://github.com/americanexpress/unify-jdocs

This article got my attention. Related to what you are saying, in Java, the problem that I was really fed up of was creating domain specific JSON object models to map the JSON documents into to use in code. In other words, mapping JSON to rigidly typed language structure. Its boiler plate, is tedious to do (as the author points out in the article), difficult to change and usually a pain. I solved this problem by creating unify-jdocs which completely eliminates the need to create object models or POJO classes to represent your JSON object. You can read more about it here -> https://github.com/americanexpress/unify-jdocs I hope it helps you and others.

Hi HN. I would like to show unify-flowret – yet another Java orchestration engine!

You may wonder – why another orchestration engine when there are already so many. We have off the shelf commercial “heavyweights”, the open source frameworks like AWS step functions / Uber Cadence / Netflix Conductor and a host of others. They why another one?

Simple, simplicity! Most of the orchestration engines I worked with or evaluated were too heavy weight or too cumbersome or too complex. Some you could build your entire careers on and some required complex DSLs, some required hacks to do parallel processing, many required their own separate server setup etc. I wanted something really simple which had all the features to create a complex workflow and yet was simple and no more. So I present unify-flowret.

Unify-flowret is a lightweight Java orchestration engine which gives you all features to implement your workflow. It is a small JAR file which can be embedded in your applications. Below is a feature summary:

1. True technical parallel processing

2. “Resume from where you left off” functionality

3. Support for any data store / database

4. Can be run and tested stand alone on a laptop without the steps being implemented (mocked)

5. Allows steps to specify “execute next on resume” or “execute self on resume” in case of non-error pends

6. Special persist step to tell the application to persist data (if not persisting at each step)

7. Comprehensive audit logging

8. Crash proof – resumes from where the information was last recorded without any manual intervention

9. Ticket management – a “go to” feature for a process

10. Support for process variables – available to each step and route to reference and update

11. Support for handling in flight applications by locking the process definition to a process instance

12. Application call back events for house keeping

13. SLA milestone framework and work basket management

At American Express, we use it to power many of our workflows and it has been able to meet all complex requirements thrown up till date. I hope this work will help many who have experienced working with orchestration engines difficult in the first place. I look forward to comments and feedback from the community. Thanks to American Express for open sourcing this piece of work which i truly think has the potential to help a lot of people in the wider Java development community.

Read more about it on https://github.com/americanexpress/unify-flowret.

Disclaimer -> #ViewsMyOwn.

All OK except when you need the same level of performance for those 0.001% of requests when the GC kicks in and takes the response time outside acceptable limits. Due to this reason alone, my company is planning to move off a popular Java based API gateway and to a C++ envoy side car implemented service mesh. And I am wondering if this is really worth it.

There are a lot of points which I simply cannot agree with. 1) concurrency as an issue - you make it sound as if doing concurrent programming in Java is hard. Its not if you read through the documentation. In todays world of spinning up small servers, when done right, it scales to massive levels. 2) Blocking threads, memory contention etc. - i think you may be comparing against the likes of single thread programming models like Vert.x or Node.js etc. The flip side which in my opinion is more severe is that if you get even a small thing wrong on the other side, it blows up even more which is more difficult to isolate and debug. Plus the need to learn a whole new programming paradigm which is not easy to wrap your head around. 3) Lot of tech companies seem to make it work - while I agree that corporates will pretty much make everything seem to work, it requires a few engineers who understand software design principles to create design and abstractions that work well. You imply that only PhDs understand that kind of stuff whereas I am sayin that there are many other who understand and who are genuinely making things work in the Java world. I can tell you, when concurrency done right in Java, it is so performance that many will simply not believe. Just my thoughts and happy to differ.

Excited to announce 1.1.0 of unify-jdocs. The new feature is the ability to compare two JSON documents easily.

Nice! As a person who very recently did a lot of looking around for the purpose of renting, I had a tough time managing my own appointments. I also found it really hard to get through to agents. Some of them would not return your calls, others mail boxes would be full, some would have their land lines advertised so you could not send a text to them. I am just thinking that this would have been a great way for me to set up viewings. I realize that your app is looking at it from the other side (that of the landlord) and for that the idea is great. I also wish there was an app that could streamline bookings for me as an individual and show them all in one place. This app is really required in today's times when people are moving from one place to the other. Great effort and all the best.

Thanks for your comment. Yes, we have a code base which is 350K LOC and growing and it takes us a few seconds in IntelliJ to look up all occurrences of a specific JSON path. The is of great help to us in refactoring in case something changes. It also helps know which path is being read and written from where due to which we are able to pin point its usage and know the exact impact

Hi HN. I would like to show unify-jdocs – a new way of working with JSON documents without using model classes or JSON schemas. Unify-jdocs is a Java library which I have created as part of working on a new technology platform in American Express. You can work with JSON documents without using model classes. It also allows you to do away with JSON schema for validation and provides a much simpler way for structure adherence and content validations. You can read AND write any JSON path including elements of an array nested any levels deep in a single line of code. There are other features like being able to merge documents and reuse model documents.

The background behind writing this library is that we have a large number of JSON document types and many of them are quite complex in terms of structure (many paths and many nested levels). I did not want to create POJO / model classes and write read and write accessor methods for manipulating data in these documents as these can be quite challenging to maintain in the face of changing document structures. I also did not want to use JSON schema validations as they tend to get quite verbose, do not mirror the JSON data document structure and can be unwieldy to use. What I did want was 1) have the ability to read and write any JSON path in a document and know metadata information (like the number of elements in an array, index of a specific element etc.) using a single line of code, 2) the ability to do fast, accurate and exhaustive impact analysis on the usage of JSON paths over the whole code base and be able to refactor quickly in case positions of JSON paths changed in the document structure and 3) the ability to conform to predefined document structures and specify field validations which would automatically get done in the background. This library does all this and more.

Before starting work on this library, I did look around to see if something similar existed. I did find some which could be used to read and write simple JSON paths but could not handle the complex scenarios which we wanted to address. I am happy to report that the use of this library in our project has made working with JSON documents an order of magnitude easier, reduced boilerplate lines of code by nearly 90% (primarily due to no POJO / model classes, accessor methods and validations) and made it extremely easy to refactor code in case paths are updated in the document. For reference, we have over 250 JSON document types, more than 2000 JSON paths nested more than 10 levels deep in multiple documents which we have been successfully able to manage using this library.

I hope this work will help many who have experienced working with POJO / model classes and JSON schema validations to be far too tedious and challenging to maintain in the long run. This is my first creation on open source (better late than never) and I look forward to comments and feedback from the community. Thanks to my employer American Express for open sourcing this piece of work which i truly think has the potential to help a lot of people in the wider Java development community.

Disclaimer -> #ViewsMyOwn.