-
I’ve been working remotely from the Philippines. 4-day work weeks. So far, it’s been great but there are tradeoffs that devs need to be aware of. Generally speaking, I’m a lot more productive and I don’t feel disconnected from the team I’m part of back in the States. You have to jealously guard your work time and I’ve found it’s best to have a dedicated place to work that is free of distraction (for me that’s a spare bedroom I’ve converted into my office).
Some of what I thought would be downsides are actually advantages. Down here in the Philippines I mostly work in the evenings and early mornings when the tropical heat cools down; midday is “siesta time”, so I adjust to the culture and this also puts me closer to US workday overlap where my evening is morning in the States.
One real downside is the quality of internet connectivity if you want to work like this from the developing world. I have the best fiber optic internet money can buy but peak times here can still be a bit slow when committing or cloning repositories, and the tech infrastructure here is notoriously bad. I change my DNS servers to Google’s or OpenDNS and I can also pretty easily work around peak time lags. So no worries.
-
One real downside is the quality of internet connectivity if you want to work like this from the developing world.
I guess it varies quite widely by country, because when I lived in Thailand the broadband was just as fast as what I had in the US and half the price. I wasn’t even in a big metropolitan area; it was a city of 120,000. It was similar when I visited my parents in Malaysia, though they had some weird restrictions like having medium.com blocked for hosting content that exposed corruption in their government.
-
Yes, I’d say there are only pockets of SE Asia where this is the case, like the Philippines. In places with much more modern infrastructure (I have Singapore in mind), you can expect fast internet and absolutely no issues doing heavy downloading or uploading of work and cloud computing.
-
-
-
I used Google Wave briefly to plan a trip with some friends. It had a lot of potential, actually.
-
-
As a developer who moved from Linux to the macOS platform, this made me think about how many non-native apps I use as replacements for the Apple version. The obvious ones I’m thinking of:
- Alfred instead of Spotlight
- iTerm2 instead of Terminal
- Dropbox instead of iCloud
- Chrome instead of Safari
- Gmail instead of Mail
- Google Maps instead of Maps
- VLC instead of iMovie
- Spotify instead of iTunes
- Signal instead of Messages
&c. This surely isn’t a good trend for Apple to allow to continue.
-
That’s not what’s meant by “native” in this case. Alfred, iTerm, Dropbox, Chrome, and VLC are native. Spotify is Electron, and I’m not sure about Signal. I’m guessing it’s probably a native app that does most of its UI in a WebView.
-
-
As it might be useful to describe what is meant by native, it means something on a spectrum between “using the platform-supplied libraries and UI widgets”, i.e. Cocoa and “not a wrapped browser or Electron app”, so it’s not clear whether an application using the Qt framework would be considered “native”. It could be delivered through the App Store and subject to the sandbox restrictions, so fits the bill for a “native” app in the original post, but it would also not be using the native platform features which are presumably seen as Apple’s competitive advantage for the purpose of the same post.
-
I’d call QT native. It doesn’t use the native widgets, but then neither do most applications that are available on multiple platforms.
-
It may be native, but it’s not Mac-native in the sense Gruber was talking about. You will find that all three uses of “native” in his article appear as “native Cocoa apps” or “native Mac apps”. He is talking about a quite specific sense of native: apps that integrate seamlessly with all of the MacOS UI conventions (services, system-wide text substitutions, native emoji picker, drag & drop behaviours, proxy icons, and a myriad more). Qt apps do not.
-
-
-
-
-
Apps with good experiences that aren’t available on other platforms keep users around. Third-party iOS apps do a better job of moving iPhones than anything else Apple does, because people who already have a pile of iOS apps they use generally buy new iPhones.
Electron is just the latest in a long series of cross-platform app toolkits, and it has the same problems that every other one has had: look & feel, perceived inefficiency, and for the OS vendor, doesn’t provide a moat.
-
Counterpoint, their apps have always been limited and really for people who weren’t willing to learn and use more robust tooling. I mean how many professionals use iMovie.
-
-
-
-
How do you all think this development is going to affect the Atom vs VS Code editor space?
So far they’ve only said they’ll build tighter GitHub integration into VS Code. I really see why they had to buy GitHub in order to build that integration; I think that’s just them virtue-signalling by placing emphasis on one of many QoL improvements they could’ve added to their editor.
*don’t