Which is a noble sentiment but simply doesn't happen in the business world (or in many other places). So the hard question is, how do you effectively encourage business to choose the best people regardless of gender?
Some have tried blind interviews but these are very hard to do properly and effectively. A 40% quota is another way to push business into looking beyond gender.
> Which is a noble sentiment but simply doesn't happen in the business world (or in many other places).
On the contrary, all the evidence I've seen points to discrimination being a very small part of the gender pay gap.
The problem is that men and women are different.[1] So it becomes very difficult to even measure if women are being discriminated against much or are just different to men.
I think there are three potential issues with this, firstly, minorities are being discriminated against and paid less in the scenario so it wouldn't be desirable on that metric. Secondly competition in many markets isn't robust enough to have an even playing field if you wanted to start a new company with all "minorities". Third, if the company was all "minorities" you would be drastically reducing the hiring pool so even with good competition it would be hard to hire well (which could wipe out any minor efficiency gains).
As someone who just recently CDN hell, and rebuilt our entire CDN network from the ground up (software and hardware), I was wondering why you picked RoR?
It’s what I know best and what I’m most productive in. The project is to get something running and learn a handful of new things, and learning a new framework would be a detriment to that first goal.
The manager app is not in the hot path with this design so performance doesn’t matter all that much.
Just be careful, understand that if you do a PULL only CDN, you're not going to gain big benefits. If you do want a pull only CDN, have a background task runner to retrieve the files, and update them locally.
Sure. I have Nginx set to keep files around for s long time and serve stale and refresh in the background, but proactively refreshing periodically is a good idea.
Personally I would build it in something like Go. I've done a lot of work in Rails and I would probably have the signup/profile/interface built in Rails 5.2 but use a high performant go framework for the really intensive stuff.
I've been considering building my own but getting an up and running gossip protocol to have it share data between nodes isn't the easiest thing in the world to code.
Its a pain to code. I’ve done it, and I hated every second of it. Keeping data in sync with dynamic data in near real-time is terrible.
I wrote the CDN in Go, with Redis and a smaller go-powered daemon to retrieve assets every 20 seconds, sync them to a local storage drive, and after 5 days retrieve again - or, if there is no requests within 48 hours, clear the unused items.
Then I setup a system that if one edge requests an “unpopular” file, it’ll ping a simple REST API and have all the other edges pull that file, this allowing the edges to stay “one step ahead” of the user load
Yeah, when thinking it through personally it comes down to a hard math problem. Because you have to maintain the state of the local files, whether they should live in memory vs ssd vs another node. Did you use an LRU cache for expunging less utilized resources?
State is much less important to track. It’s easier to do, the real challenge is garbage collection - you need it, but you don’t want to collect too much in memory. That’s why Redis is a great tool for our edge servers.
And nothing has made me realize just how slow the speed of light is until I started looking into the CAP theorem and distributed databases like CockroachDB.
1. Someone you can trust
2. Someone you’re not afraid to speak up with or against, without fear of repercussion personally within reason (ie, if you call each other crap every day, you’re not a good match most of the time)
Instead of asking me to complete some boring challenge, bring me into your office, and let me help solve a real issue you’re facing, then at least we both don’t waste our time on challenges that only prove you have free time on your hands.
I’ve searched local circles to see if there’s someone I’m not best friends with, someone I can argue with, with no long term feelings in the line, and can feel I trust.
My plans for future cloud platforms are to have the ability to create your own platform file, that’ll house all the required code to get it running, and then having a simple command to install them, ie...
ignite install —platform {platform_name}
All platform code will be saved in your home directory under a folder called .ignite, ie: /home/Michael/.ignite/platforms/Heroku ...etc
This new platform design will be in the next update, and you’ll be able to generate a base template by doing...
ignite create —provider {provider_name}
Then in terms of sharing the provider file, and all its sub files, you would do the same ignite share command, with a flag of —provider, and then it’s a matter of sharing and installing it.
Apex is very good, but I draw the line when it comes to being reproducible universally, the goal of ignite is to be an AIO package that can manage configuration, dependencies, and deployment without having to create complex structures for deployment/sharing/etc, and the key factor is everything that is created must be reproducible regardless of platform, IDE, etc. and that’s why Ignite exists, to help take away that pain and just have a very simple CLI do the tasks automatically
