497 karma · joined April 16, 2020
But in general, if you're buying the cheapest labor you can find, you're going to get an inferior product.
It's like captaining a ship and not being willing to repair the ship. Good luck on your own I guess.
It's different when they already have a product and are looking to expand. That's closer to hiring a sailor to manage the sails. But when you're hiring a ship builder expect a ship builders wage.
Also, don't hire a college kid to build your MVP. That's a big enough red flag right there.
1) Have a small domain
2) Have a large resolution
3) Have a very long initial load time
Any of these suck for game development.
Analogies should "simplify" not complicate. If you're ever writing an analogy and think "How can I add more meat to this? You know, enough to make it worth sharing in a blog post?" you're on the wrong path.
I'm hoping for things more impactful than yet another dashboard but something is better than nothing
My perspective is every form of communication bears certain unspoken rules / implications.
* Email - This is a serious thought out discussion
* Slack / Similar in a shared channel - This is office-formal, you should be professional but can joke around. Similar to how you would talk to an equal or your manager in person
* Slack / similar in DM - This is a rapid "Quick question" forum where you just need some links or quick thoughts. Nothing here is very serious
* Phone call - This is informal, rapid discussion for time sensitive issues. I'm calling you so that I don't have to page you.
I've been in this field for ~7 years and have never found this to be true, yet people parrot it all the same. I have never once received a job via reference, and only once was able to get someone else a job by reference. I feel this is only true when you're at the very senior level.
Both of these aren't real incentives for the bottom 80% of postdocs.
Start with . and .*, then add additional stuff as you get comfortable
I mean. Fair enough. I guess.
That argument won't work in practice though. You have to make it make financial sense to each and every individual to encourage them to switch, "Do it because it's the right thing to do" is a tall order when people are already on a tight budget.
I'm sure the new US president will assist in this matter.
Anyways the phrasing of the non-blocked article seems to imply the title is a red herring, and their bill actually went down. I'll never know though.
It gets old.
To that end, I'm not clear on benefit in this model. To solve that problem I would just take a centralized framework and stick it inside an oversized drone/vehicle capable of carrying the added weight (in CPU, battery, etc.). There are several centralized models that don't require an external data connection
> the resources on the robots, which are idle otherwise, are used
But what's the benefit of this? I don't see the use case of needing the swarm to perform lots of calculations beyond the ones required for it's own navigation & communication with others. I suppose I could imagine a chain of these 'idle' drones acting as a communication relay between two separate, active hives. But the benefit there seems marginal.
> our system also don’t rely on such central point of failure
This seems like the primary upside, and it's a big one. I'm imagining a disaster or military situation where natural or human forces could be trying to disable the hive. Now instead of knocking out a single mothership ATV - each and every drone need to be removed to full disable it. Big advantage.
> We are just currently working on a “group” abstraction
Makes sense to me. That's the 'value add', might as well really spec that out
> leader election to determine a “mothership” among the group
This seems perfectly reasonable to me and doesn't remove the advantages of the disconnected "hive". But I do find it funny that the solution to decentralization seems to be simply having the centralization move around easily / flexibly. It's not a hive of peers, it's a hive of temporary kings.
After opening the site I had to "fail" a couple just to understand what the user goal even was. I recognized the fake/misleading UI but still wasn't sure what to do with that information.
I think you should take this exact concept, do some user studies, and come out with a V2. There's a market for this. My grandparents are getting to the age where I don't really trust them with access to their own credit cards / operating the web, I frequently come over to fix their computer and it's just extensions they've unintentionally installed. If this was iterated on & repackaged as either a educational course or a "test" to see if they are "safe on the internet", I would pay money for it.
And on the other end, it's well-proven at this point that tech literacy for the average person peaked somewhere around people born in 1985-2000. Before then, people grew up without as much access to tech. After that, people grew up in an environment where common tech problems were already solved. (A 10 yearold in 2012 wasn't dealing with corrupted disks, they were playing on an iPad). Offering this concept as a course targetted at the age range could be good.
Can you provide some insight as to why this would be preferred over an orchestration server? In this context - Would a 'mothership'/Wheel-and-spoke drone responsible for controlling the rest of the hive be considered an orchestration server?
This isn't my area of expertise but I think "Hive mind drones" tickles every engineer.
It's a language guys. It won't give you a BJ