The thing is..owning capital isnt what it used to be with jewels piling up. Credit allows debt backed by that physical collateral to be used for someones tractor to be built. These people may be 'worth' a lot of money but their wealth is actually more diversified and illiquid than the average person's capital. I think its an important distinction because we can easily lose sight when we don't realize that one person's wealth isn't a zero sum loss for the rest of us. In a credit debt economy, we still lose but not binary..more like a percentage. Their money is out there doing work, helping other people. They can call it back eventually..but if someone is so rich they never actually recall their 'floating' assets, is it economically scientific to consider those assets equal to cash under a mattress? I feel like we need a new measure for almost perpetually floating assets so we dont consider ownership as relevant.
Nice, this is perfect timing for me to see this actually. I've been slowly building out a little cli tool that I use to track .env files (and other files that you don't want to check into source) in a git repository that is parallel to your project's git repository.
The way it works is you identify a file that you don't want to check into source. The cli moves it to a parallel repo, commits the file to the parallel repo, and symlinks the file back to the original location.
From then on, you get all of the normal source control features like local changes, revision history, etc... that you get with every other file in your project. I basically got fed up with "crap what was that value I was using before? Let me dig through my credentials store" or resorting to commenting out old lines just in case I needed to revert.
So far, I've just been keeping those parallel repositories local for lack of an encrypted remote to push to. Definitely checking this out.
> I can't explain exactly why I think those factors make it suspicious, however.
I think I have an idea of why, though I haven't been able to articulate it properly yet.
I've been thinking about it a lot recently because I co-work with a bunch of digital marketers, and some of them have affiliate marketing sites with domains that follow the pattern http://yourexactsearchterm.com.
The best I can come up with is the Uncanny Valley of SEO, where it feels like a website was made and over-optimized specifically for people making my exact search query. Maybe this is unfair or confirmation bias, but I feel like those websites are the most likely to be low quality content farms (e.g. paying content writers pennies to regurgitate content they have no experience with and/or don't understand). Either that, or they are outright scams.
Do any digital marketers here have opinions about this?
"Uncanny Valley of SEO" sounds like the best explanation --- and in my experience, sites with names like you describe have also tended to be content farms.
It's not just domain names, but the paths in URLs too --- an entry with your-exact-search-term.html almost subconsciously gets skipped over when scanning search results, unless the search term is extremely specific and somewhat obscure or I'm specifically looking for a file/path (e.g. spc4r37.pdf)
That's actually a really awesome idea. I wonder what the threshold of adoption would have to be before that signal is widely understood. Maybe that should become a necessary safety feature of driverless cars to replace the "feature" of being able to see what the driver is paying attention to through the window.
Yes, hurricanes are destructive, especially to human settlements, but I'd be surprised if there aren't massive ecological benefits to hurricanes in spite of (or possibly because of) the destruction. Forest fires, for example, have well-documented, long-term ecological benefits. Unfortunately it looks like hurricanes aren't studied as much as forest fires.
Just doing some cursory researching online [1] [2], it looks like they basically act as dramatic "flushing" mechanisms:
- end droughts
- distribute heat from the equator towards the poles
- seed dispersal
- redistribute soil/sediments along coastlines and inlane
All these things could have beneficial ecological purposes...IN moderation... but what happens when they go to extremes ala Climate Change.. when we have 15 cat 5 hurricanes per year..or burn 10 million acres of forest per year...etc..
How much of our current excelling weather patterns are a result of global warming? All interesting questions...
Time logging. I use one piece of software to track my time, then fan those time logs out into the various pieces of software that need to know about them.
For anyone else who has never heard of greenwashing like me two minutes ago:
> Greenwashing is like whitewashing with a green (environmental) brush: companies and organizations making themselves and their products sound or look like they’re really helping the environment. And they lure you in — creating the perception that you can help, too. In some cases you are helping. In some cases, it’s greenwashing.
A typical all-in-one framework is Ruby on Rails. It is great to quickly start a project that does basic things planned for by the framework.
But as your project grows, and you start to need special, custom things (and you inevitably do), you understand the "Rails" part. You have to move along the rails. This leads to a growing number of ugly hacks, just to keep the whole thing within one framework. The problem is that you can't replace one component you want different. Everything is cross-dependent, aka "integrated".
In the long term, libraries rock, and monolithic frameworks suck. But in the beginning, the lure of a monolithic framework us strong.
What drives me insane about Angular, both 1.x and 2.x, is the sheer amount of idiosyncratic boilerplate required to merely get started and do things the "framework way". It's unreal, though of course Angular 2.x takes that to a whole new level. AngularJS could at least be written in vim without boilerplate generators and meta-meta-meta tooling.
I suppose the thinking behind all these services, providers and factories was that they give mediocre developers that don't really know how to program a more common vocabulary and a set of childproof "design patterns" to grok — that's always easier from a management perspective than giving people who don't really know what they're doing the freedom to architect. But it just frustrates the snot out of actual developers who just want to be left alone and resent having to shoehorn their _entire_ application code base into some framework's mandatory structure, by way of which there are still yet more APIs and conventions to learn and with whose changes it is necessary to keep up ...
In this sense, Vue wins very big. It handles data binding and rendering/UI generally, but in no way premeditates how the rest of my JS is going to work.
So ... actual developers are people who don't work on teams for large scale applications? Because what you call "childproofing" is basically the most obvious tenets of a shared codebase.
Sure, but there's a subtle difference between having to adhere to shared internal conventions and structure vs. having to adopt some overly complicated and constricting external framework's contrived conventions so that (in theory) a few people don't drive the bus off the cliff as often.
Citation needed.