wasyl

They still should've handled it differently. Show a warning to the user encouraging them to migrate, give a reasonable window before the feature is actually disabled, and don't let the users upgrade to a version which will break their storage.

Synology made a mistake which they admit:

> DSM incorrectly allowed administrators to migrate from a BTRFS-capable device and utilize previously created BTRFS volumes on the affected devices

And they're punishing users for it

This is absurd, how did nobody in charge realize that a storage/backup device which intentionally renders the data unavailable after any update, not just a patch, is absolutely crazy? And now I'm anxious to update my DS920+ which it seems is not affected by this change but am I willing to risk _any_ updates at this point?

They do? I don't have any plugin installed and use Zoom in Firefox without major issues

It's not an easy switch. Still most of the examples and articles are in Groovy. Until recently, IDE (IntelliJ) support for Gradle Kotlin DSL was abysmal (like analysing stuff on the main thread). Only recently it's getting more traction as the worst issues have been resolved.

> There is hardly any Android conference without build related performance improvement talks.

fwiw I think the Android toolchain being slow doesn't help. On the same conferences someone will also speak about how the new Android Gradle Plugin is X% faster, so it's not all Gradle's fault :) That said there's plenty more Gradle can do (and is doing) to improve performance. The startup cost to configure all tasks is definitely high on my annoyances list

Adding to that, in IntelliJ it's as simple as running the task from the 'run Gradle task' window (not sure how it's called) with Shift pressed. All the breakpoints in the build scripts will now work.

If you also use wrapper with sources (`-all` instead of `-bin` suffix in the `gradle/wrapper/gradle-wrapper.properties`) you can step into the entire Gradle source code as well

Coming from Gradle, it always baffles me how there's no wrapper for every popular tool out there. I'm always confused by the venvs, rbenvs, and overall managing multiple versions of the toolchain for different projects. In Gradle it's just so simple, and with toolchains support [1] it's going to be a very predictable build environment with just a simple `./gradlew` invocation.

[1] https://docs.gradle.org/current/userguide/toolchains.html

> Scoping is mysterious

It definitely is confusing, but while the rules to scoping are pretty extensive, they're also well defined. The trick is to know how Gradle "travels" through objects and looks for the property in class properties, extensions, extras, etc. I wrote about it [1] if you're interested.

> Gradle script is interacting with things you can't see

Not necessarily -- yes, the receiver for top-level calls (Project instance) is implicit, but you can access it via `project` property. You could prefix each top-level call in your Gradle script with `project.`, making all calls explicit.

Btw `sourceSets { }` calls the lambda on a `SourceSetContainer` instance, accessible via `Project#sourceSets` property [2], so you can get an instance of it. I suppose there might some objects that are configurable but not accessible, but nothing comes to my mind right away, actually.

> a build tool is a thing that tracks dependencies so that it only has to rebuild things whose inputs have changed. Gradle doesn't do that at all.

You might've had a bad experience with a misconfigured plugin/build or a bug. Gradle does track dependencies, and while it doesn't do that perfectly always, it avoids a lot of unnecessary work, on many layers (incremental compilation, task avoidance, task caching). As a general rule, when running the same task(s) twice, the second invocation shouldn't execute any taks.

> This is because the entire dependency graph is constructed dynamically on every run It's true that configuration/task graph creation is still happening on every invocation (this will change with Configuration Cache [3]). But it's definitely not accurate that this prevents Gradle from knowing which steps have already been done. Again, I fully believe it didn't work for you, but it doesn't mean Gradle doesn't do that.

I'm not trying to say Gradle doesn't have flaws. In fact, I think your comment proves the points from the article. Unless one invests in learning how Gradle works, it's impossible to spot e.g. why the build isn't doing any task avoidance, or understand scoping. It's rather unfortunate, because after that initial investment Gradle is a pretty great tool to work with.

[1] https://medium.com/tooploox/where-do-gradle-properties-come-... [2] https://docs.gradle.org/current/dsl/org.gradle.api.Project.h... [3] https://docs.gradle.org/current/userguide/configuration_cach...

It's definitely not the first study, I've seen at least 2 or 3 other since March (no links though, sorry). Also the only study that suggested the opposite was a simulation that I think wasn't even peer-reviewed.

I'd say visibility and it's super easy to start. Even if you want a simple github-hosted static blog, there's just a lot more to do than just opening a website and writing in simple markdown

On the other hand, each of the phones I and the people around me have have different standard for fast charging. So even if I wanted to share the charger with someone or use one that I current own, I'd be losing on that benefit

You might find this interesting, not exactly generating a minesweeper without guesses but close https://pwmarcz.pl/blog/kaboom/

> if a software developer does not like hacking around with software they are probably in the wrong career

This is some gatekeeping right here. There's a lot more to developing software than hacking and dealing with low level linux configuration just to get my graphics and sound working at the same time after a system update

I think Kotlin is ahead enough in this area that it'll win. Plus it's much easier to compile Kotlin to native and use that from Swift than to use native from Java/Kotlin

> more pressure on these same apps to implement Sign In with Apple Afair this is actually a requirement: if you have email/facebook sign in option, you need to implement Sign In with Apple as well

`source:domain` is also useful for organisations, when you want to search not only files that you've opened, but everything public or visible to you in the entire org (or at least that was the case ~a year ago)

It's amazing how bad Slack got. Android app looks slick and the UX is awesome, but functional bugs make up for it: last week I had all _my_ messages disappear from a conversation, I could only see what the other person wrote. I routinely have to force-close and reopen the app to have it show new messages. And for couple of months now, smileys typed in the app (e.g. `:)`) don't convert to actual emojis when sent. Support responded recently along the lines that "it should be fixed now because nobody complains anymore". Well it isn't, apparently sending a smiley to try and reproduce the issue is too much of an effort.

That's a nice trick, thank you! Although even knowing _what_ I had to do, I only managed to learn this after couple tries.

Why would leaving with a non-compete be so bad that the owner thought they somehow had an upper hand?

I see lots of these business notebooks come with 8GB of RAM. Is it really enough for most users? I assumed 16GB should be the standard by now, especially with how memory hungry day-to-day software is.

Seems like Slack is focusing a lot on making the app more accessible for enterprises with email-like message composer or "no-fancy-shortcuts" navigation. While some of these improvements are nice, I feel like Slack has been going downhill ux-wise for some time now:

- new input box, obviously, which messes up the message even when turned off (edited message with code block will often be different than what I just sent)

- people with message drafts moving on the list, as many people mentioned here already

- often an action I did by mistake can't be undone by pressing escape: drafting a post, opening image. I can't reproduce this always so it seems like a bug

- I now sometimes can't see person's details by clicking their image for some reason? I need to click their name, but even that not always works. Also not reproducible 100% of the time, so looks like a bug

- notifications on Android are broken: they don't disappear when I read a message elsewhere, sometimes I get mobile notifications _for a conversation I'm having on the desktop_.

- when I write someone with notifications off/snoozed, I'm immediately pinged about this. And every single time I'm thinking that person maybe is online and replied, but it's always Slack pinging me, with notification and all, that it's actually the opposite

- I often see people working while appearing offline, myself included, because apparently Slack decided to stop asking if I want to go online after I decline it once or twice (the night before)

Basically Slack is less and less friendly. I used to advocate for it as it was a huge step up from HipChat that we used, but if it was up to me now, I'd be looking for alternatives.

Feels to me it would be in company's interest only if the salaries were more transparent. Otherwise company will pay as little as they can to keep the person working for them, even if that's well below the value the employee delivers. If the employee doesn't realize that, they'll just stay. And as long as the company doesn't lose good employees, there's no incentive for them to pay people more.

For a free, self-hosted CI I strongly recommend TeamCity -- if you can get away with 3 build agents and 100 configurations that come with the free version.

I was in your boots some time ago, managing CI before I convinced the company that paying for a hosted CI is cheaper than me maintaining our self-hosted whatever CI we were trying at that point :) Jenkins was atrocious and I spent ungodly amount of time dealing with all kinds of issues, while TeamCity was mostly configure-and-forget. Initial setup is pretty straightforward, so is later migration to a real database for example. Updates are seamless and we had some projects on it even after we started using paid CI (Bitrise), because there was no motivation to migrate as everything was running smoothly.

Nice! I've been considering trying out Bazel for an Android project but didn't get around to it yet. How is the IDE support (Android Studio and/or IntelliJ)? And how is actual Android support in Bazel, for example in terms of feature modules, app bundles, DataBinding (that I guess is supported as a regular annotation processor) and third party plugins like Firebase? How much of a dealbreaker is it if I have to use a complex 3rd party Gradle plugin that I wouldn't want to rewrite for Bazel?

> completely undocumented tool

Gradle is far from "completely undocumented". Unless you mean Android Gradle Plugin, which surprisingly _is_ somewhat documented, although the docs are tough to accidentaly just stumble by

While it's likely true, GCM/FCM is handled by Google Play Services, which is whitelisted and has I believe system-level permissions. It has less restrictions than a regular app exempt from battery optimisations, as it's supposed to be the only app that needs to run in order to coordinate things like push messages or location updates across all apps on the device

edit: I missed that the original post was talking about keep-alives and you were probably referring to them. But how app-level optimisations can help with keep-alives?

Not only that, but for many manufacturers this will straight up either not work after the app has been in the background for some (not long) time, or will deliver (that is, app will be able to connect and receive) push notifications with significant delay. Sadly, most reliable way I know to trigger push notifications when app is closed is using FCM - I'd love hear if there's an alternative, though.

Major thing for Android developers is that the adoption of new Android versions is so slow, we're really stuck with Java 6/7 features. While backend can happily update to Java 15 on their own terms, we're limited by Android OEMs to provide updates to their phones. This is one of the reasons Kotlin is so popular with Android -- you get new Kotlin features when you want to, not when all of your app users buy new hardware (and good luck convincing business people to ditch 10% of the users on old API versions). While we get support for Java 8 (but not 9 or 10) language features via special tool, we still don't have access to Java 8+ APIs.

Could Blizzard deny signing the Processor agreement, thus effectively limiting the access to their, otherwise public, API?

Huh, and how do I reinstall the patch? Can't find a downloading link and app store doesn't let me do anything with the update

Funny thing is that on the update site section steps in `To confirm that your Mac has Security Update 2017-001` confirm that I have the update, but am still vulnerable to the issue.

Do I understand correctly that setting root password is also valid workaround for the issue?