Maybe consider that we have literally hundreds of priority tasks, all of which are legitimately very important, and that while we can spend the time necessary to install and maintain non-turnkey solutions, we’d really prefer to work on one of the other priorities with that time.
There’s no such thing as general tech priorities, it’s just an amalgam of a bunch of individual priorities. In most of the cases I’ve seen those priorities are very reasonable. If you start a tech company and prioritize fiddling with internal messaging software over building your product, you’re going to fail. Prioritizing tech doesn’t mean yak shaving every random task, it means outsourcing as many non-essential tasks as you possibly can so that you have as much time and attention as possible for the one specific technical task that matters: building your product.
I don't think priorities shifted away from tech, they just moved up the value chain. Tech companies should focus their limited resources on building their core product, not managing "plumbing" like email servers or chat.
I replaced Rails with PostgREST, which is written in Haskell but for me as a user is just a binary that I run in front of my database, so now I don’t have to write any backend code at all.
The following isn’t the top reason I recommend Postgres, but is the reason I think least likely to be echoed in a dozen other comments:
Postgres has some of the best documentation of any software product I’ve ever used. If someone wants to learn about SQL or databases, I always have to restrain myself from recommending that they just read the Postgres manual front to back. It’s comprehensive, it’s well written, it’s easy to navigate, and almost every explanation comes with several clear examples. It’s hard to overstate how valuable a property that is for a product as central to your architecture as your primary transactional database.
Too many Open Source developers discount the value of documentation. I all too often hear, "It's Open Source so the community should step up and write the documentation." To which I counter that the best person/people to at least start the documentation are the ones who build the product as they're the most knowledgeable about it. The community will gladly contribute. I personally believe that great documentation was a big reason for PHP's success in the early days.
My pet peeve is great software with incomplete documentation.
All that hard work put into the code, just give us a quick example of how to actually use it! Especially where there is maybe a super superficial example, but missing examples of how to use the optional yet essential and non-straight forward arguments/features.
Oh! I have a much bigger pet peeve for projects which have a fine and moderately-usable examples section, but then decide that's good enough and never document the API because one should just "look at the examples".
This. By chance I started reading the manual for Postgres yesterday and it actually filled some holes I had in knowledge. It's amazingly structured and verbose with extremely clear examples. The PG manual is literally a 0-to-hero resource for everything SQL related.
It may have a good doc but searchability on the internet is still miles behind MySQL and that actually counts more on daily search for answers.
Also I sometimes don't know if I should search with psql or pgsql or postgres or postgresql and I tend to type shorter ones but mysql is quite obvious on that.
I once did exactly as parent suggested and read the thing as a PDF on my phone, more or less sequentially, in downtime that I would otherwise have wasted. My knowledge of SQL and databases improved immensely.
To be fair I think I skipped some of the appendix matter relating to niche use cases.
My background is more like yours. For me it’s likely a difference in size and type of companies worked for.
> I was hoping that the article would explain what devops really means today and how I can jump on the devops wagon to hopefully make my job of doing all of the above easier.
1. Use AWS Fargate for all of your backend services. Keep the architecture simple enough that complicated service discovery issues etc don’t come up. If you need coordination between services, do it through Redis or similar.
2. Use RDS unless you really need to save money or use unavailable extensions.
3. Use terraform for initially provisioning the above
4. Set up CI/CD such that merges to master automatically update your services. (I like CircleCI’s aws-ecr and aws-ecs orbs for this.)
Pretty simple recipe, but it means no setting up servers, no hardening servers, no installing or optimizing software (other than by adding it to the Dockerfile), no installing or optimizing the database.
This recommendation reflects what modern devops means to me; opinions differ. To me it means:
- Infrastructure as code (terraform rather than clicking buttons in the AWS console then later forgetting which buttons you clicked)
- Immutable infrastructure (aka cattle not pets). Never SSHing into a server again.
- Automated testing and deployment cleanly integrated with existing dev workflow
Obviously there’s a scale at which you have to do something more complex, but I’d say that’s the scale at which you previously would have had an operations team.
Getting rid of the “writing server side code” and “writing front end code” parts is beyond the scope of devops, but you can skip a lot of the “writing server side code” part by using PostgREST. In exchange you may have to write an even-more-untold number of SQL queries, depending on your current practices.
Edit: Someone helpfully pointed out that I forgot to mention anything about logging or monitoring, which is a pretty glaring omission. On that front I strongly recommend Honeycomb. To set it up with Fargate you may need to run it in a sidecar container, but it’s fairly straightforward.
I’m using Fargate for almost everything now, and am never going back. It’s extremely simple and easy, does exactly what it says it does, and saves me a ton of time and headaches. (I use Terraform to set up services, and CircleCI (with the ECS orb) to deploy updates.)
What happens with Fargate if you need to SSH into the underlying instance? I haven't used it myself, and I'm not sure that it truly abstracts away the EC2 instance, but the description of Fargate always made me assume that to be the case.
I assume eatonphil is correct, but to be honest I’ve never even tried, and in my view that’s actually part of the point: full commitment to immutable infrastructure, made really easy. If something needs to change, I tweak the Dockerfile or the task definition or a config file and redeploy. No more SSH.
I've also gone over those lectures a couple of times. I'm not even sure why I started watching them, since I knew absolutely nothing about linear dynamical systems before hand, but it really changed my life! It taught me techniques that I now use all the time, and I think are very neglected within my field (data analysis/forecasting).
If your not familiar with it, it's an extremely versatile framework for modeling and analysis of all kinds of systems. It will give you new insights into linear algebra, time series analysis, stochastic models, Fourier analysis, Laplace transforms, and many other areas.
He's a brilliant (and enthusiastic) teacher, and he has lots of resources on line, including a text-book length exercise-set which I've printed out and had bound because it is so awesome.
adventured is having a really hard time with your phrase "two identical companies". The answer to your question is yes, if you had two identical companies and then gave one of them $10B in cash, that company would be worth $10B more.
Actually adventured is right on non-operating cash being usually discounted. In general the second company will not be valued at $10bn more than the first.
Would you rather have a $1 in cash and a $9 share in the first company, or a $10 share in the second company where $1 is the cash per share? The second case is more risky so you wouldn't pay the full extra $1 for the second share.
Of course it could also be the case that the spread is larger than $1, if the first company is too short on cash and there is a liquidity risk depressing the valuation.
Not if they're otherwise identical companies, it isn't. There may be reasons to expect a correlation between risk and cash holdings, or something to that effect, but ultimately a share in a company is a share of ownership of that company's assets. If a company didn't become $10B more valuable when given $10B in cash, where exactly did that value disappear to? Value doesn't vanish into thin air simply because it's now owned by a company.
> The digital economy is giving us a world in which the benefits are concentrated among consumers and the Big Five who serve them. Everyone else just lives in it.
This is a really weird phrase. "Concentrated among consumers"? More than 80% of Americans use the internet, not exactly "concentrated".
I think people on both sides of this issue would love it if the law showed itself capable of handling sexual harassment cases. Unfortunately we have way too much evidence that that just isn't the case. The obvious example that comes to mind is Brock Turner getting three months, and that's in the best case where someone is actually convicted. Far too often it never gets to that point, not because the harassment/assault didn't occur, but because the legal system is so utterly shit at handling it. The 'outragism' that so many people decry only exists in the first place because every system that is supposed to prevent or punish these acts has failed so completely.
And we have even MORE evidence that companies ALWAYS mishandle these cases with BLATANT conflicts of interest.
You're basically arguing that companies should become their own units of law enforcement with their own punishments as they see fit, with no oversight. That is clearly not going to work. It clearly hasn't.
If the law is unfair, we have the power to change that law. Exceptions always exist but we can not make laws on exceptions. Meanwhile companies continue to allow harassment on a daily basis, Look at Fox News. Multiple cases. Imagine in other corporations?
I'm arguing nothing of the sort. While it probably feels good to strawman everyone who disagrees with you, it certainly isn't helping you persuade anyone, nor is it allowing you to learn from other perspectives.
While we may theoretically have the power to change the way law enforcement works on these issues, doing so would be dramatically more difficult than making marginal improvements within the industry itself. We shouldn't let the perfect be the enemy of the good.
Please do without the smug BS first paragraph next time. Try forming a real argument instead. Thanks.
Industry has never gotten this right. How long until we finally see that the company trying to avoid bad PR and make money doesn't have conflicts of interest with these victims?
I've seen too many companies turn blind eyes to terrible workplace environments because the perpetrator "makes too many sales." or is "too important." It's always going to be a conflict of interest.
My advice to anyone is: collect evidence, quit, and file a lawsuit. Any other internal method will lead to even more abuse and fear.
'Not useless' is not a high enough bar in software. Flexibility always adds complexity, and complexity is a cost. Sometimes that cost is worth it, but the benefit needs to be much larger and clearer than 'not useless'.
Not a high enough bar for what exactly? So far this entire thread is a lot of vague talk spawning off the idea that it doesn't solve a problem. That's the statement I don't agree with. If enough people decided to use it, that's the only bar that actually matters. But it clearly solves a problem, just not necessarily a problem every Emacs user has.
