Why not just replace the code with "No one can possibly behave poorly for the project, just believe everyone" and be done with it? Seems equally effective.
Even today on the Atlasian docs, they provide a Docker image of Confluence to evaluate, but if you buy a production license, you are required to build an OracleJRE Docker container (they provide instructions) for production.
It's been years and they still can't support OpenJDK ... it makes me wonder what weird proprietary crazy reflection shit they're doing in there.
The approach I've taken, which I think is common and slow and easy to "fall off the bandwagon", is to write my solutions to my problems on my blog or email the J mailing list and see if the experts can improve on my code. They always can, if they care enough to show me, and they usually do. But as I mentioned in my other comment, I think one of the wonders of APL/J/etc. is that it seems to share even less with conventional programming languages than it seems to at first because the way APL programmers decompose problems is radically different. I often find myself trolling through the dictionary looking for things that I wouldn't need if I didn't break the program down into as small pieces. Choosing the right verb is partly tactical, but the whole strategy for attacking problems is so unconventional you are often looking from the wrong vantage point.
I don't know if there is a royal road to APL that addresses this, but I share Hillel's desire for one. I suspect there isn't, and the only way to really get better is: read lots of code, write lots of code, get feedback on your code, repeat.
I wish this could be easier.
The example image given can be re-compressed using techniques like structural similarity (SSIM) or Multi-scale structural similarity (2008 Paper). Using jpeg-archive I resized the example image in the blog with decent results:
/tmp ls -1sh *.jpg *.png | sort -nr
Reverend Jim (on Daniweb)
Motorbikes don't generate world class sprinters either but they sure get you from A to B faster than walking.
Turns out, Al Gore doesn't like it, either: https://www.typotheque.com/blog/gores_choice
Also, you can't usually specify DNS servers on cellular connections. The VPN setup would address that.
Somewhere I read a helpful way to rephrase "blockchain" that really helps cut to the heart of the issue when you're dealing with technical questions like this: The blockchain is just an ordered series of files, each of which contains a hash of the previous one in the series.
So, when you've got someone saying, "What if we use blockchain?", just mentally substitute the suggestion as, "What if we store the data as an ordered series of files, each of which contains a hash of the previous one in the series?" Any bits of the proposed system that aren't impacted by the decision to store the data as an ordered series of files, each of which contains a hash of the previous one in the series, also don't have anything to do with whether or not it needs to involve a blockchain.
Yes (and no), but that's not what IBM is selling with their blockchain. They're selling trust, but only providing a digital trust solution while completely ignoring the physical and human side of trust.
> There is value in not having to connect to a central database all the time.
Problem here is IBM's blockchain is still a centrally maintained database. This literally provides any value. You still need to connect to a central database at some point.
But I think Block chain can succeed. It matters less that it works, as long as the rich and powerful believe it can help then sustain their status.
Most distros use the IceTea builds for OpenJDK. Hmm . IceTea3 is Java8. There's no Java9 IceTea4 build yet. I can't find any roadmap info on their site ...
I consider this 3d rendering as a spectrum: rasterization requires little computation but has little to do with physics. Ray tracing is what requires a lot of computation and has everything to do with physics. Somewhere in between are hybrid methods: rasterization with ray tracing components added to it, or ray tracing with approximations.
For instance, pure rasterization cannot do shadows. It is approximated by rendering the scene from the viewpoint of a light and test the rasterized scene for occlusions casting shadows. And the other way around: real time ray tracing cannot compute all indirect lighting paths, a subset is only considered at the cost of e.g. variance.