Full Screen your chrome, then leverage ont this plugin for URL box
Enjoying Chrome in Completely Full Screen mode even without omnibox (Zen). Leave the address typing to ZenHelper.
Note: This is still beta stage, new feature WIP.
Had exactly this discussion the other day among several strong opinioned programmer.
View at Medium.com
After all its technology both still in exist, and the exist is with a reason. It’s ultimately boil down to personal preference, but neither should be forced as superior.
it’s not a completely novel requirement to get the status for asynchronous processing, for example, to get the file upload progress, to get the order status, alert for processing failures etc.
IMO, there are mostly two approaches for it,
whether it’s through REST/GraphQL/Queue/DB/FS, if the client is polling for status, that’s a synchronous call, which kind of patched for the original fire and forget async process.
this would still be a patch for the original async process, however, it’s really valid. since it’s a “new” requirement from the client to get the status. instead of polling, which almost removed the merits of the original async call, the client could expose a webhook for the server to post back status asynchronously. as such, even though it’s a patch, it will be patched async, leave both processes fire and forget.
recently i have a need to build/start/stop some sibling containers (vs docker within docker), the way to do it is to expose a pipelien from the host to the container:
for single container:
docker run -v /var/run/docker.sock:/var/run/docker.sock
for docker compose
View at Medium.com
actually the dameon could listen from other host (configuration):
have encountered some issue with the stale dockerfile. turns out, docker compose actually cache previous builds (this is not stated in the doc).
so to keep it updated, need to run build without cache then bring it up.
docker-compose build --no-cache && docker-compose up
history is full of similarity.
this is such a repeat of WSDL2Java vs Java2WSDL debate. personally, it’s nothing black or white, right or wrong, similar to the ORM vs mybatis, it’s just opposite design suitable for individual use cases.
it might be true that Google or Facebook has some monorepo alive since more than a decade or two decades ago, however, that doesn’t means it’s the right approach for any new projects to adapt in 2019.
tech has been improving on loose coupling and SoC, which is a design idea since GOF and even earlier. this has continuously generating the benefits from version control, project segregation, building, CI/CD and micro services, which resulted faster and better quality delivery and long term maintenance. I will be surprised if monorepo would flourish in next decade or any near future.
quite interesting to see all those ideas/noises/debates come back and forth though.
View at Medium.com
it’s a dilemma, the reason why the language become more popular, (especially among the new or maybe amateur programmers) is due to its loose design, easy to learn (at the cost of not to leverage on the static typing, multi-threading concurrency, and JIT and AOTs for example), which is the exact reason for its being not as performing as the other languages.
Its been around a decade since MS tried to emulate the success of java, ever since j++ to. Net c#.
MS is a java shop now.
Java is not only de facto langue for thoughtful enterprise app, its ability to keep evolving from several years release cycle to half yearly, and with so many version poped up each with up to date features design principal, yet as the same time as backward compatible as possible (its unimaginable of the python versioning issue from a java world.) java is very mature stable language yet growing at even faster speed than any new lanagues with the very solid design carefully thought of language principle, its able to grow even faster and at the same time as always stable and trustworthy.
Years back, it was very much a hassle and careful thought process to build the right projet skeleton with the right code structure and inline libraries. After that it’s another equally if not more challenging to pave the runway for the poc to build test deploy and put on suitable scale of Web servers/ containers, application server, and databases with normalisation and vertical horizontal scaling.
All these efforts have now significantly saved thanks to all new frameworks which bundle all these together, providing an optioned suite.
With the popular of the frameworks and tools, then come with now a new challenges, which is to properly leverage on the tools.
Aws for example, has shoot up from single digit toolset size to now probably hundred.
Container has gone from vm chroot jail docker cluster k8s swam.
There is definitely value added to have the skills (DevOps or admin or infra) to pave the right platforms at this era.
However, I won’t be surprised as tide moves, there will be tools to bundle these tools together and save all these skills or effort in future. For example, the recent Pivotal conference to ask developers to forget k8s.