We have worked with flutter since 2019; having built internal apps for our staff, public apps for our customers, small utility apps etc- this has been our experience as well. Not only flutter has been rock solid, easy and fast to develop, it has a wide array of libraries. Long may it continue.
Tailscale is just a commercial service that builds upon wireguard. It automatically generates certificates for each of your devices, ensures they're rotated and up to date, automatically configures routing and DNS between your devices and offers some additional functionality.
Tailscale has open source clients but a proprietary server to do this, but you can use the open source alternative headscale instead: https://github.com/juanfont/headscale
Convenience. you're free to run wireguard yourself, but that's a lot of faffing about with config files that some people don't want to do. and then on top of that, they have clients for mobile and eg AppleTV. that may be outside your use case, but some find it handy.
> New users will not be able to sign up for Fig's products right now while we focus on optimizing them for existing customers and addressing some needs identified to integrate Fig with AWS.
I love Ruby, but I always wonder if performance will be an issue if there're many things happening on screen especially on mobile. Does anyone has any experience?
I'm new to this whole thing. Can u point me on how I don't depend 100% on CF, if its DNS is down? Is there such a service? (kinda like load balancing, but with DNS?)
DNS is easy. You can (and must) have multiple nameservers for your domain. Just use different companies (and different regions) and if one goes down the others will still resolve.
You’re not alone. I’ve been migrating my tables to use uuid instead of integers and have been using uuid whenever I have new tables, unless I have very good reason not to. Experience was my teacher.
Destroy is a strong word (and UUIDs can certainly be sorted, but locality is an issue), but all of software is a series of tradeoffs. I've used both auto-increment and UUIDs, and wish I had used UUIDs in almost every case.
Distributed generation - no sending a record to a server to get a key then using it to generate other records. In a world with increasing use of services, this becomes more important every day.
System wide unique - helps with logging, debugging, and avoiding general errors.
Multi-master db replication - I know this depends on the RDBMS, but having a unique key on every record avoids clashes. Also super useful during data migrations (which will happen. I have another rant that data always outlives code, so plan accordingly).
Validation - UUIDs have a form that can be a first level validation on input.
For me, those advantages outweigh some extra space usage, possible performance impact, and ugly URLs.
And on performance, if it's determined that it is an issue because of using UUIDs there are ways to make them more index friendly.
There is a perf hit. You can not help it when you are slugging that many bytes around. An int/int64 fits into a register easy and the instruction for comparison is cheap. However, when you add in replication and other items UUID becomes more desirable due to the property having extra information embedded into it to make them unique. You can get some of the same benefits with more complexity if you are using auto increment. Such as using a stride that is similar to the number of machines you have in the cluster. But even that can get weird, and depending on your db can be a pain to setup. Using them as a cluster index and you probably will most certainly create a hotspot index and poor lookup performance, but decent write. Just due to the fact that items probably are not grouped the same as your where clause. SSD's have hidden most of this for most databases. But the issues are the same.
They don't utterly destroy performance, but there is some hit if you use UUID v4 random values due to database index scattering. That's why this new proposal exists. It adds new versions of UUID that are mostly incrementing in time, so that they group better.
In my experience, thats a big NO. While there is some performance impact, in other ways it can actually be a benefit (spreading writes out to multiple pages, for example) so as with anything in regards to performance: benchmark, benchmark, benchmark.
PS.: UUID's also work quite nicely to deal with certain system hiccups, specifically temporal ones. Could be thought of as something similar to the Erlang supervisor trees.
+1 for TablePlus! I absolutely love them for the fast editing as well as quick and dirty filters. Beats typing SQL for simple stuff. These quality of life features are really underrated. Absolutely worth the yearly fee!
I feel like they see themselves as a database management tool, but with just a few tweaks (good UI for working with relations), could be a FileMaker / Airtable contender.
Interesting. I’m a rails developer, and to me one of the core strength of rails is active record (altho some might disagree). How would you compare it with rails active record, and which part do you say it’s much better?
Btw, I know this is superfluous and very shallow, but for some reason, I can’t get over the C# syntax because of how enterprisey it is. I much prefer ruby, but I guess it’s a matter of preferences and taste
Enterprisey usually means high-overhead, tuned to require many developers to achieve what would be done by one on a less enterprisey
system.
This quality is attractive to managers who benefit by increased headcount, and prefer to have their "reports" or "resources" less generally capable, and more easily replaced or shuffled. Total cost is much higher, but individuals' salaries are lower, which makes managers look good.
Java and .Net are both very enterprisey platforms.
You understand that all the things done in Java and .NET’s “enterprisy” way can be done is most languages right?
This is a programmer problem not a programming language one. Today you have to write less in C# than GoLang, to do the same tasks. Does that mean GoLang is enterprisey now, just because you have to write more?
Not "just because". Go is exactly as enterprisey as Java and C#, and for exactly all the same reasons.
And, it is not a programmer problem. It is a management problem. None of them would exist without management demand for minimally-productive languages.
What a weird hill to die on. I have a hard time believing “management” woke up one day and said: “how can we make the most minimally productive language”.
Tell me about this secret non “enterprisey” stack you are using.
Management does not make languages. They use what exists that satisfies their need for large head count. Sun and Microsoft were happy to provide it for them.
