Google releases the Cloud Run Button to quickly launch apps to Google Cloud Platform from GitHub
A new button from Google serves as an embeddable image or link that developers can add to their code repositories so that others can quickly deploy project code to Google Cloud Platform using Cloud Run, Google’s serverless container deployment service that competes with Amazon’s Fargate and Microsoft Azure’s Container Instances.
The Cloud Run Button works with any repository that contains a Dockerfile. According to the team at Google, “when you click the Cloud Run Button to deploy an application, it packages the application source code as a container image, pushes it to Google Container Registry, and deploys it on Cloud Run.” Cloud Run is priced using a pay-per-use model, but each resource has a free quota that should help drive adoption of the new deployment tool.
Containerization has advanced significantly over the last few years; Google’s Cloud Run button is the latest demonstration of the simplicity with which you can deploy containerized applications to the cloud. Containerized code can be packaged and shared from anywhere, capable of being deployed from online repositories to the cloud without ever needing a local device. So, while modern development tools have minimized friction between local machines and the cloud, they have also reduced friction between online developer tools.
A new interconnectedness between online development tools highlights the interesting relationship between cloud services and GitHub. As the home for much of the world’s source code, a number of tools and services try to integrate with publicly available repositories to stoke virality. For Google, tapping into the GitHub ecosystem makes sense, especially when Google does not have a similarly robust community of its own. By offering its own button, Google can cut out middleman services and enable richer app deployments that better capture Google Cloud’s full capabilities.
As GitHub now operates more closely within the Microsoft developer ecosystem, Azure seems almost inevitable to add a similar feature. As services integrate more closely with GitHub, expect a more vibrant and diverse ecosystem of tools that serve as an unofficial development layer on top of public code repositories.
Standard, a popular npm package, is a style guide, linter, and automatic code fixer that helps developers format code and ensure consistent style across their codebase. With nearly 200k weekly downloads and used by roughly 80k GitHub repositories, Standard is a well-known and much-used library in the development community.
The developer community had a largely unfavorable reaction to the decision to allow ads in the terminal. Many developers complained that the ads would complicate debugging by muddying logs. Other developers noted that packages often use multiple dependencies, leading to a bizarre situation where terminals could potentially be bombarded by multiple nested ads. After the backlash, Linode pulled its support from the project and removed its ads from the platform. A few creative developers even built a first-of-its-kind ad blocker for the command line should the sponsors return.
Many agree that open source software has a serious funding problem. Other developer-led initiatives have sprung up over the past few years to fix the lack of funding in the open source ecosystem. One such tool, OpenCollective, helped projects show donation requests in a post-installation terminal message. The project gained traction and is now (sometimes begrudgingly) accepted by many developers.
The lack of easy funding raises an important question: should open source projects penalize individual developers or should they demand more from big technology companies that often benefit greatly from open source projects? Tapping into an entire development community for funding is lucrative and far easier to implement for open source projects of any size, but the strategy risks alienating the very users that help promote project virality. Conversely, partnering with big tech companies can comfortably sustain many open source tools, but can potentially subject projects to outside interests and make them more vulnerable to significant dips in funding should any sponsors drop their support. No solution is without its faults.
Standard deserves acknowledgement for seeking out creative alternatives to secure funding for the open source world, but will need to be wary of disrupting developer workflows.
United we stand, divided we fall: proposal to split PHP into two separate languages is unanimously rejected
A proposal suggesting that PHP should be separated into two languages has been rejected by all fifty-three PHP members that govern the future of PHP development. The original proposal requested that a new PHP dialect, dubbed P++, be created to add new features and improvements to modernize the PHP language. Development would continue on both PHP and P++, with PHP preserving backwards compatibility with the entire PHP ecosystem.
PHP is a divisive language, with many developers bemoaning its slow evolution. While many developers prefer PHP as a dynamic language with an emphasis on simplicity, other developers that support the creation of P++ hope to create a dialect that is strictly typed, a significant deviation from PHP’s long-standing philosophy. Creating a new strictly typed dialect, according to these developers, would help them add more complex and advanced features. P++ would also be able to carry on development with less baggage, removing old or difficult to maintain features of PHP in favor of faster innovation.
P++ would live alongside PHP and share much of the same code, but would likely face a number of serious obstacles. The PHP development team would still need to maintain two versions of certain parts of the codebase. And, while developers would install both PHP and P++ as a single language, most development teams would likely want to pick one for most of their development. For teams with legacy PHP code, converting existing PHP code to P++ would be a nontrivial task and PHP tools would likely not support P++ at launch.
- Focus and deep work — your secret weapons to becoming a 10X developer [FREECODECAMP]
- Things I learnt from a senior software engineer: lessons from a human log [NEIL KAKKAR]
- Software is eating the world and Git is the fork with which it is being eaten [JAN]
- Nobody really owns product work [SVN]
- Avoid premature optimization [VICTOR ZHOU]
- Real-Time-Voice-Cloning helps you clone a voice in five seconds to generate arbitrary speech in real-time [GITHUB]
- Postwoman is an online, open source API request builder [GITHUB]
- Monolith will bundle any web page into a single HTML file [GITHUB]
- SourceSort will help you find the perfect open source projects to contribute to [SOURCESORT]
- Shaai is a pluggable blogging framework [SHAAI]
- Code Line Daily highlights one interesting line of code per day [CLD]
Every week, our team will send you three of the most important stories for developers, including our analysis of why they matter. Software development changes fast, but src is your secret weapon to stay up to date in the developer world.
Today global initiatives on AI are a series of regulatory and ethical gambles—a dangerous, potentially existential game.
Why the Xbox will be Azure’s unlikely hero.
Understanding churn rates can help developers be more productive and write quality code