So to summarize Qt would lead to shoe horning in all the things that are simple
to do and constantly being improved and optimized with Angular or ReactJS and
most of the use cases I mentioned are not supported.
Quality > quantity
True but you have a really good quality indicator in the number of downloads
per module on the NPM page. For example take the superagent REST client
written by TJ Holowaychuck (Also authored the express framework). So for a
quality indicator just review the stats:
https://www.npmjs.com/package/superagent
* *65,261*downloads in the last day
* *1,421,783*downloads in the last week
* *5,688,991*downloads in the last month
Worst of all he wrote it when he was 6 years old while taking a break from a
Photography shoot.
and need I bring up the left-pad fiasco? There's no
namespacing on npm
It's called an @organization. For instance angular lives under @angular.
, and the artifacts aren't even immutable!
Most of the popular packages use semver guidelines. You can also shrinkwrap
the build.
It took how
many build tools before reproducible builds were possible? (yarn)
Been using NPM for years now and reproducible builds have always just worked.
They introduced a glitch while introducing package-lock.json, but it was fixed
quickly (I hope) :). Also with all the traffic around Angular, in addition to
the weight that Google puts behind it, the builds will be reproducible.
It could also lead to more sharply focused feature development in Log4J.
Like what? Log4j has been rather healthy with feature development,
especially in comparison to literally every other JVM logging solution in
existence.
Absolutely - I love the new log4j features. That's why I'm on this list. However
logging feels like it's a bit of an after thought when it comes to development. I've
seen very few articles detailing out "This is how you use logging to nail down
issues with this type of scenario". This is when you trigger a switch from the info
log level to the warn log level realtime, etc. In other words a type of methodology
around logging that is integrated with how we think about developing the application /
server in general and how we go about using logging results on a day to day basis.
So we have all these tool - Spring has the Actuator - we have ELK, Zipkin,
fluentd, Elastic Search, Log4J + other things you mentioned in your last
article - but what is the best way to put all this together and integrate it
into the development design flow so that the logging solution is an integrated
part of the final product that minimally invasive, easy to setup and monitor,
and user / dev ops friendly.
In this case you could just flip to the app and see the logging alerts
real time via a socket connection. The app could also vibrate your phone
if the S*** is going down. You would just configure the app to talk to the
notification server. It could give you rich and informative realtime
visualization of how an attack on your network and services is unfolding /
how nodes are performing overall and peaceful pictures of koala bears
eating leaves when everything is under control. You know no one can resist
Koalas!
This could be a useful app, though it's rather orthogonal to Chainsaw IMO.
Well it's just food for thought ... I definitely think it would bring Chainsaw
back into the game and pump up log4j in general .... If there is a doable
vision articulated around it then interested parties would know where and how
to contribute ... I don't think this would hurt anyones resume ...
