SmileyKeith

Yea that one is fine and well covered in the blog post, and pretty easy to spot in light testing. I'm much more worried about the ones that are harder to spot until you have a false negative that turns into a real bug which would be caught by 1 tool and not another.

Can you add some examples of the things users care about that aren't well covered by this? I empathize with everyone who wants a feature comparison chart so they can be confident switching without unknowingly losing important safety checks.

Original YouTube link: https://www.youtube.com/watch?v=yD2JaAnMMo0

Looks like someone filed an issue about this https://github.com/bluewhalesystems/sold/issues/35

That has been there for a while so I think it's still an open question of if this change of strategy applies to that repo too

This isn't the primary part of this conversation but I found this quote pretty interesting:

Now, we are starting to work on Safari again but look at Chrome. They put out releases at least every month while we basically do it once a year.

Even though this was in 2013 nothing about the release cycle (still only major changes with the major OS release versions). I wonder if some of the other emails have more context on this.

I've had similar problems contributing to bazel (Google's open source build tool) for the past few years. I've found contributing only goes smoothly if there is a single Googler working in your area who cares about open source. Otherwise everything is very Google centric and the open source community is definitely a secondary concern (which is of course their right!)

FYI your website's CSS on mobile causes unexpected horizontal scrolling issues

Daily. I find it a great way to follow many low frequency blogs without having to fill my twitter feed or email with them.

Github seems to be primarily focused on becoming a social network

I never hit the GitHub.com homepage so I never see any of this work. I always start directly on a repo, notifications, or search.

Even the slack requires an @google.com email to get in.

This shouldn't be the case, I'm in this slack and it's mostly non-google folks. Do you see this at https://slack.bazel.build ?

In this case I meant taking an approach similar to this one for bazel[0] that is not limited to only code that works on Linux. It would only allow you to build on Linux and would require any testing / running would still happen on macOS, but that might still be worth it in some cases. Theoretically you could deploy your iOS app that way as well.

[0] https://github.com/apple-cross-toolchain/rules_applecross

For bazel users there is also this project[0] which runs the tools natively on Linux without requiring this layer. Although you lose tools like ibtool / actool which don't have open source re-implementations.

[0] https://github.com/apple-cross-toolchain/rules_applecross

This does generally work, but it requires a lot of manual effort to setup the environment correctly with Xcode's SDKs to satisfy the compiler / linker.

An Apple employee tweeted after the news with 11.0 that this was a bug so I'm not surprised, but happy to see it fixed!

The entire pbxproj format is horrible, but at least you have stuff like BUCK (https://buckbuild.com/) that can mitigate some of that.

FWIW I'm still not sure what the BUCK workflow is suppose to look like for most teams. It seems like if you use BUCK you're expected to not use Xcode even as an editor, yet there isn't another editor to pick up the slack (assuming you want autocompletion and decent highlighting). I think there's still a lot of work to be done for it to be a viable replacement, even for Objective-C, for Swift it's even further away.

The videos from many WWDC sessions are altered. So even if you got the right session it may not have this. I've been in sessions where much less interesting this have happened that haven't made it in to the video. Also last WWDC they started pre-recording sessions so they could be up on the web sooner. Many of the video sessions from last year don't have any audience noise and differ significantly from the live session.

That is fixed in an open PR: https://github.com/XVimProject/XVim/pull/1016

XVim[0] still works well if you're willing to resign Xcode. There are simple instructions in INSTALL_Xcode8.md.

0: https://github.com/XVimProject/XVim

Here's another new one to try http://dejalu.me/ (from one of the creators of Sparrow)

One really nice benefit is that you don't have to duplicate any type information. Once you define your model with the data types you expect, mapper infers those types and converts the JSON values accordingly. It seems like with SwiftyJSON (which I haven't used) you have to duplicate this by calling things like `.stringValue` etc.

That doesn't remove all of the associated preferences, caches, and other stuff the application could have left around.

It actually is on GitHub[0]. I'm not sure why it wasn't mentioned in the mailing list.

[0] https://github.com/martanne/vis

This was a lot funnier before GitHub introduced the current folder mechanics. Since you previously had to dig into each level.

I love seeing this on the front page. I've been a Vim user for a few years and feel like there isn't a ton of help out there for switching to emacs + evil.

This looks nice but there are a ton of issues around pyobjc. I've never been able to successfully install it on 10.9.

I thought about making one of these but chose to go with the ErgoDox instead. The entirely split layout of the ErgoDox is really nice. That along with more keys sold it for me. 42 keys just isn't enough in my opinion.

Yep. At the time it was still in beta though.

To me the more important part is the interface and thread safety.

Swizzling is a weird one in the community. But if I see #import <objc/runtime.h> something has gone wrong (you have to include that for swizzling and other seemingly dangerous stuff)