GitHub Makes It Easier to Work Where Maybe You Shouldn’t – InApps Technology 2022

I still remember getting my first smartphone back in early 2010, and how exciting it was. I could take pictures wherever I went, check-in with my friends on Foursquare in competition for some imaginary internet points, and even respond to emails from anywhere in the world! What freedom!

Soon enough, as a burgeoning tech blogger, I’d hacked together various applications to ping me whenever news broke, whenever certain people posted to Twitter, whenever numerous companies posted new blogs that might be seen as tech news, and the next thing I knew, my phone was buzzing in my pocket incessantly at all hours of the day.

Within two years’ time, I’d completely burned myself out and canceled my cell service, relegating myself for several years to internet access only where wifi was available, as a response.

I tell this brief tale as my own personal anecdote of tech burnout, of the double-edged sword that is having everything immediately at your fingertips no matter when or where you are. These days, I’ve found a much better balance, turning off push notifications on numerous apps and often keeping my phone on silent, but it remains a struggle. I remain defensive over the invasion of technology, and therefore work, into every aspect of daily life, and so I immediately thought of this upon reading that GitHub was proudly touting even better code review in its GitHub for mobile apps.

And I wasn’t the only one to question the excitement around this news.

“hey I know you’re out with your family, but I really need to get this PR out can you take a look on your phone real quick?”

— stevey p (@whichsteveyp) October 14, 2020

In its introduction, GitHub writes that it “heard from users who use the app to review code while taking a walk or sipping coffee on their balcony. Oh, or boating down the Amazon river.” While that Amazon river example may sound glorious, don’t you think that, perhaps, sitting on the balcony sipping coffee or taking a walk might just be the perfect time to NOT look at a screen for once? As might floating down the Amazon river? Haven’t we looked at enough screens lately, especially during the online extravaganza that is 2020?

These aren’t people just “triaging notifications in the app–they’re reviewing and merging code,” GitHub writes, as a point to back up how good it is that this will now be even easier. And perhaps that is one point: If you’re going to be out there reviewing and merging code instead of, oh, I don’t know, being present in the world around you, at least you’ll do it easier and quicker now.

Guys, this will lead to even more crappy software: people will hastily look at code from their phones, maybe while waiting for the bus… Did you consider the usefulness of what you are doing?

— Gennaro Prota (@gennaro_prota) October 14, 2020

Of course, many folks don’t seem at all concerned, but rather excited at the prospect of properly wrapped code for small mobile screens or the new “jump to” button for reviewing larger files. And if you are one of those developers excited to spend your time reviewing merge requests while you walk the dog, head on over and grab the newly updated GitHub app for Android or iOS, and get excited, because GitHub Enterprise Server will be supported later this year.

Maybe, if GitHub’s example was instead “sitting on the toilet” instead of “taking a walk” or “floating down the Amazon river,” I might have been more into the idea…but likely not.

Nat nobody wants to review code on the toilet

— James Willcox (@snorp) October 14, 2020

This Week in Programming

• Easier Code Review Comes to GitLab 13.5: The soon-to-be-released GitLab 13.5 will be making code reviews easier with the introduction of merge request “reviewers” as separate and distinct parties, making it more clear who is doing the requesting and who is responsible for the reviewing. The feature will allow authors to request a review and see the status of the review, and those assigned reviewer status will be notified of the request to review the merge request. Up next for GitLab, they plan on adding features to suggest the most relevant reviewers and streamline the approval rules to be more clear with the introduction of the new “reviewers” role. The new reviewer feature will roll out on Oct. 22, and those who want to participate in the discussion around the new feature can visit the reviewers epic in the GitLab project.
• Android Studio 4.1 Addresses Editing, Debugging, Optimization: This week saw the release of Android Studio 4.1, which introduces features to address “common editing, debugging, and optimization use cases” while looking to make users more productive while using Android Jetpack libraries. As with previous releases, the team continues to focus on the quality of Android Studio, hunting down bugs and performance issues, of which it says it has “fixed 2,370 bugs and closed 275 public issues.” If you’re looking to upgrade, download Android Studio 4.1 now, or check out the video below for a quick overview of all the changes.

• Kotlin Goes to Six Month Release Cadence: The folks over at JetBrains have said that they have decided on a new release cadence for Kotlin and the IntelliJ Kotlin Plugin, with a Kotlin 1.X release every six months, instead of when features are ready, and the Kotlin IDE plugin released simultaneously with Kotlin and every time IntelliJ IDEA is released. The change is intended to provide a more regular scheduled release of standard improvements regardless of whether or not big language changes were in the pipeline, which previously determined when releases would occur. Moving forward there will be three types of releases — feature, incremental, and bug fixes — and features will arrive twice yearly in spring and autumn, incremental releases (which do not include language changes, only compiler improvements) will ship between the major releases, and bug fixes will “possibly, but not necessarily, follow incremental releases.” All of this, they write, is with the hope that these changes will “speed up the language progress even more.”

full-stack react in 2020: you can now write .jsx files that we’ll turn into routes for you and render server-side so the browser just receives HTML

PHP: am I a joke to you

— I Am Devloper (@iamdevloper) October 14, 2020

• Monaco Editor Comes to nteract: The Python team at Microsoft has brought the power of its Monaco Editor to nteract, which builds SDKs, applications, and libraries to make the most of interactive notebooks and REPL code editors. Some features that come with the addition of Monaco include theming, autocompletions powered by the Jupyter kernel, and the ability to rename all instances of a variable within a cell at once. To get started using Monaco, navigate to the Preferences tab in the top toolbar in the latest nteract version and select “Monaco Editor” under Editor Type.
• The Serverless Debate Rages On: Some technologies seem to just lend themselves to constant questions, and serverless sure is one. This week, an article on InfoQ asks why the serverless revolution has stalled, pointing to limited languages, vendor lock-in, and performance as the primary reasons. If this sounds like the internet debate you want to waste your Saturday on, head on over to Hacker News and get in on the fun.

things the javascript event loop runs in: a thread

— yan (@bcrypt) October 15, 2020