914 karma · joined February 24, 2015
http://blog.hiphipjorge.com http://github.com/thejsj @thejsj
[ my public key: https://keybase.io/hiphipjorge; my proof: https://keybase.io/hiphipjorge/sigs/riy2CCnAkatc4s8M-k75giCncH26I6tmDcqerprOFeg ]
The air industry seems like a good example of just the right level of regulation: There's tons of competition, different pricing tiers with their corresponding levels of quality, and a lot of dynamism combined with a good set of consumer base regulations (24 hour cancellation period, for example).
One example of that is something like he adapted a shader we use internally to render font glyphs, which no one has touched ever since. The engineer who told me this had spent a few days trying to understand it and said (after having worked in this area for years) was stumped by it.
It will be, yes! I do think it should work. I think I'm slightly worried about how much is appropriate given an unspecified time commitment.
> But no one, especially early on when they're small or solo, wants to go hire a lawyer to write these contracts. I wonder if we can create good templates for rev/profit shares for solo/indie/bootstrapped businesses. Think the SAFE that YC created, but more around profit or revenue shares.
Think this is a fantastic idea actually! I think there's a lot of projects out there that would benefit from this type of risk sharing in a way that would make sense for both parties.
> If this is interesting to you shoot me a msg would love to talk to others who are seeing this type of problem.
I'll definitely do that. Let me try to do a bit more research on my part too!
> Also, if you know Gumroad, they're building out a new product called Flexile.com that enables companies to hire contractors but also give them equity/dividends. It's not released yet, but may be worth looking into and getting on the waiting list. May or may not solve this exact problem but it's in a similar realm.
Super interesting. Will go and check it out!
This is the only statement in the post I honestly disagreed with. Anton is trying to talk about how his coworkers have lost historical perspective and that he, because of the geopolitical situation of the space in which he was born, has more historical perspective and therefore believes that everything might got s**. It's a very valid argument.
Yet, I have 2 questions: - Doesn't the fact that there's a large group of people in the world (in North America, Europe, and other places) that believe in the stability of the system indicate that maybe they're actually experiencing history at a slower pace than their ancestors? - More importantly, isn't the intent to predict history by claiming to understand a change in the way it operates (in this case its speed) also a lack of historical perspective?
Otherwise completely understood the point + liked the idea.
I started thinking about this a bit and I came up with the conclusion that the single biggest difference between structs and shapes is really iterating over keys. I spent some time trying to create structs by which you could iterate over all the keys and all the solutions seemed clunky or inelegant.
Also, it's fast! I'm in total agreement with the point made in the article. That makes a huge difference in developer UX.
For a lot of the people that get to that level of wealth, it was never about the money. It was always about something else. I don't think the Bezos, Zuckerbergs, and Musks of the world wake up every morning wanting to make more money. They find fulfillment in their work. The external recognition is not bad either.
I think you're right that some people who want to continue making money are mentally ill, but there are other reasons people continue working. For some, the money is just a byproduct.
One of my friends is travelling+working across western states, but he's the only person I know. Another friend tried going to Truckee (Tahoe) and eventually ended up back with his parents after a couple of months.
So far, I would guess this is happening but to a much lesser extent that what most think. It'll definitely be a trending in that direction though.
But, I do think that users do notice the difference. I think you're right that they'll "feel" an application hogging their CPU more than they'll feel one doing so with memory, but they can tell when an application is faster/slower. I think this is especially true with video calling.
So the bet is not su much that you're open up Activity Monitor and track CPU or memory, but rather that you'll "feel" how the app does perform better. And yes, I could be totally wrong about it!
All that being said, Watercooler definitely has a long way to go when it comes to this. There's a bunch of stuff I plan to do in order to improve performance.
Yes, this is going to my own signaling server. No way around that. The signalling logic is very minimal though and no audio or video data touches the signalling server.
> And what about encryption, is that enforced by WebRTC per se?
In WebRTC, all communication between peers is encrypted once the connection has been established.
> Lastly, are you routing calls through TURN servers if NAT tunneling with STUN/ICE fails, or always?
I do have one TURN server based in SF in case STUN/ICE fails , yes. If I see a lot of usage in other geographies, we'll probably deploy more in different regions.
I do agree with you that Electron is an amazing platform and definitely has a lot of cool, solid use cases, but that doesn't mean that every single app we use _should_ be written in Electron. Recently, it feels like every app uses Electron. Even the ones that shouldn't.
Video Conferencing is one of those apps that in my opinion should definitely be native for two important reasons: 1. Performance: Video conferencing needs great performance. As a user, you want the best video possible at the best FPS possible. Mostly Electron/JS video conferncing apps are not bad (Facebook Messenger, Google Meet) because Chrommium just provides a JS wrapper for native APIs implemented in C++. But, if you want to do anything outside of that you're screwed. You will eventually run into the limitation of what Chromium gives you and this gives you an upper limit to what you can do to optimize this. 2. Memory Usage: Video conferencing is usually used alongside other apps (while sharing your screen for example). For that reason, you want to minimize memory usage as much as possible to make it easier for the user to have the app open while using as many apps as they can. Electron uses a lot of memory.
A third reason is that the human interaction guidelines provided by Apple for their UIs (and embedded into their APIs) is very, very good. It keeps the user experience consistent across your platform and makes your app easier to understand. And this is coming from someone who is not really an Apple fanboy. What you see with Electron apps is a steeper learning curve for having to learn how to use every new app you install.
When it comes to comparing this to Zoom, I would say that the video/audio quality is just as good if you have a good internet connection and a tiny little bit of luck. Like it really truly can be and has been many times during testing. What I think the app needs to be better at is handling situations where bandwidth is not as plentiful or the system doesn't have that menu resources. That's the next thing I want to work on with this.
Re: Typo: That one escaped me last night after putting the finishing touches on this. Will fix and upload to the App Store in a bit.
If you're looking to test it out with anyone, feel free to schedule a demo (link in the landing page). The link is kinda hidden, but it's there!
Edit: Changed the copy to just "Watercooler uses less memory and than any other video conferencing app with comparable CPU."
In the future, we will probalby have other clients other than the macOS one.
Creator of Watercooler here. Happy to answer any questions!
A little more Watercooler:
For the past couple of months I’ve been doing a lot of video calls. Personally, I didn’t quite like any of the video call apps out there. The ones done in JS/Electron/Browser always felt sluggish/slow and Zoom has a very unintuitive UI and seems to be made for boring corporate meetings. I eventually decided to make a minimal video calling app of my own and hence Watercooler was born.
Watercooler’s three main characteristics are that it’s:
A) Completely, 100% native (uses the native WebRTC library)
B) High-quality video
C) Extremely simple to use (No account needed, for example)
I’ve been doing a lot of tests calls during the last month or so and almost everyone who uses it mentions one of these during our calls.
A couple of quick takeaways from working on this project:
1. The native macOS APIs (AppKit, Cocoa) are pretty good, but not a lot of people out there are using them, which makes it hard to get questions answered or find examples for things. 2. WebRTC is an amazing project. It really does solve a lot of problems. But it’s also extremely complex. One example for this is the logic for how video resolution is selected and adjusted over time. 3. Debugging video call issues can be extremely challenging without the right tooling because issues are hard to replicate and tend to “fix themselves” once they start happening. 4. While building Electron Apps seems way easier (HTML, CSS, JS over native APIs + automatic cross platform apps), integrating with the host OS makes for a really pleasant experience.
There are still some minor, hard-to-reproduce bugs that will get fixed in the next couple of days/weeks. If there’s enough demand, we’ll build out some of the big missing features like group calls and calendar integration.
Glad to answer any questions and hope you give it a try, J.
I’ve never quite understood the dynamics of this. Do people mostly self select? Is there organizational pressure to do this? Is the constant rate of change in terms of technology too exhausting for people to keep up (More senior engineers are def capable!)? In my experience I’ve seen a it of all of these, but honestly not enough examples to see clear patterns (...precisely because I’ve only worked with people in their 20s and 30s).
We're on GKE and with their new Kubernetes offering, I've considered switching but just haven't talked to a single person who uses it in production at work.
We don't have any concrete plans to tackle this right now but it is something we're definitely mindful of. Thanks for the links! We'll be sure to go through them.
Yes. We intend to run this as a cloud service API for now.
Our bet is that the simplicity of using Basilica will provide a much easier experience that doesn't require complex infrastructure and training and will provide very good results thanks to transfer learning. The amount of data needed for this is also much smaller than if you were training a model from scratch.
I interned with Ben Fry about 6, 7 years ago and think I remember him saying that he regretted naming it "Processing" because of all the reasons people mention here (google, it's a verb, sounds a bit generic, etc)