Townley

I'm rooting for them as one of the best potential guardians against the cloud provider market becoming even more of an oligopoly.

Cloud resources should be a commodity. Providers should offer compute resources, persistent storage, load balancers, and MAYBE a small handful of other services.

The way Digital Ocean succeeds against AWS is by aligning itself with this idea, and competing on specialization. Forget competing with lambda; let me run my own serverless application. Don't worry about IAM; let me configure LDAP. Don't waste developer hours on service-ifying the latest NoSQL storage trend; write high-quality tutorials explaining how users can do it themselves.

And most importantly, continue to invest into open source and community resources. There are developers willing to fight the good fight against proprietary walled gardens like AWS/GCP/Azure, but it has to get easier. Configuring HA postgres is harder than paying for RDS. Paying for GKE is more feature complete than using rancher or kubeadm to make my own kubernetes cluster. This friction is an existential threat when Azure can make my problems go away for cash.

I don't know if Digital Ocean can succeed against the big cloud providers, but if they do it won't be because they made a better platform; it'll be by playing a totally different game.

Agree that the k8s tax, as described, is a huge issue. But I think the biggest issue is immaturity of the ecosystem, with complexity coming in second. You can at least throw an expensive developer at the complexity issue.

But when it comes to reliable installations (even helm charts for major software is a coin flip in terms of whether they’ll work), fast moving versioning that reminds me of the JavaScript Wild West (the recent RBAC on by default implementation comes to mind, even if its a good thing), and unresolved problems around provider-agnostic volumes and load balancing... those are headaches that persist long after you’ve learned the difference between a replicaSet and a deployment.

Definitely crossed my mind. It'd be easy enough to submit a legitimate app and then modify the content it serves to be something malicious. No idea if/when a follow up review might catch that outside of user reporting.

But in the scenario where apple decides to no longer allow OTA updates, you're just back to the extended review process that native apps have to go through, so I think the productivity gains make it worthwhile.

Another factor when evaluating platforms to build an app with includes ease of initial submission/submission of updates.

I've never used Xamarind or flutter, but easily one of the best parts of using Expo (React-Native) was their built-in certificate management, guidance through the submission process, and eventually immediate publication of updates through running `expo publish`

My client was pleasantly speechless when I was able to change code and have it appear on her device a few seconds later, as it had been her experience that updates have to go through another review process.

Even putting aside it's approach to dependency management, Poetry has a fond place in my heart for making it so much easier to publish to PyPI.

If poetry did nothing but simply the process of publishing and updating python packages, it would still be an amazing tool.

Independent political action committees (both PACs and Super PACs) need to report their spending to the FEC, tied to the candidate their independent expenditure is in favor of/support.

That covers most political spending on the national level. Political spending for state offices (which dont have to report to the FEC) is a whole other story.

I'm mostly okay with it, though the deployment plan isn't the proper place for what's essentially a referral code.

Hashicorp is facilitating the purchase of Azure products, and deserves a cut of the revenue. But this should be handled on the account level, either on sign-up or as an account field (a-la Amazon Smile)

I'm less okay with the tracking for analytics purposes, but if Terraform finds some way to make it easy for me to tell cloud providers who sent me, that seems fair.

> a lot of developers, including long time Free Software developers, don't get licensing at all

Completely agree; it's a complex part of producing software that people (myself being guilty of this) incorrectly assume they can ignore.

> There are legitimate technical reasons for not liking Electron, not necessarily due to "disproportionate amount of time bickering" spent by "Linux Desktop users".

There are legitimate technical reasons for not choosing electron, but I can't think of any for not liking it. It's a perfectly fine and useful way to make a cross-platform desktop application. If it doesn't suit your project's purposes because of performance, size, or current acumen, that's fine.

But I think OP is referring to "Electron is awful", "I hate Electron", or "Never use Electron" levels of ire that crop up occasionally, which should be exclusively reserved for something that no one should be working in.

You might be interested in IronOx: http://ironox.com/

Indoor produce grown "by robots with love"

Cascadia looks really nice, but I worry about fonts that combine two equals signs into one long one. I can imagine getting used to it, but until I did I'd be worried about assignment-vs-equality operator bugs

This is an absurd sum, both in the fees:rewards ratio, and in the total amount ($22,500 might as well be nothing for all of the people involved).

That said, I'm a bit surprised to see a "Rake them over the coals" attitude on HN. They leaked a DB with hashed passwords, user data, and last 4 digits of credit cards. That happens to even the most responsible websites all the time, even with seven years of best practices to build upon. I know it would have absolutely happened to the awful, framework-less PHP I was writing back in 2012.

Without letting Zappos off the hook for not taking security more seriously, it seems to me that substantial, non-ridiculous monetary punishments should be reserved for instances of deliberate recklessness, or at least clear, preventable negligence.

Good point, thanks for that. Fixing now!

This wasn't the case as recently as a few years ago. I used to listen to the podcast version of Wait Wait Don't Tell Me exclusively, and remember musical interludes that immediately went right back to the show.

One time I was driving in the car at just the right time and heard Wait Wait Don't Tell Me on the radio for the first time (as opposed to in podcast form) and was startled that there were ads. Now of course there are a ton of ads, but I remember being surprised by how NPR seemed to be a holdout to the Mailchimp/Casper/Blue Apron-fueled ad craze.

One tip I didn't see mentioned (though it's pretty common in tmux) is to use the default window layouts for organizing multiple panes. You do this with Ctrl + b followed by esc + <num>.

esc + 1: All windows take up equal space horizontally, and stretch the full vertical width

esc + 2: All windows take up equal space vertically, and stretch the full vertical width

esc + 3: The first window takes up half of the screen vertically, and all remaining windows divide up the space equally

esc + 4: The first window takes up half of the screen horizontally, and all remaining windows divide up the space equally

esc + 5: Windows are divided into two equal columns horizontally, and split remaining space vertically.

Even if I have to alter the sizes a bit usually, the pre-defined layouts are super useful for positioning different windows.

I want to say it's the freedom to self-host, but really it's the CI.

Throwing a .gitlab-ci.yml file into my repo is by far the easiest way to get CI/CD incorporated into a product. The configuration of test runners (or lack thereof) is both a breeze and extremely powerful.

I'm not even talking about the auto-devops thing that I haven't tried; writing your own gitlab-ci file worked in frictionless ways that CircleCI, Travis, and (especially) Jenkins didn't.

Are there any common scenarios among Stripe users/repayment schedules where the effective APR would be advantageous compared to a traditional loan (convenience of application process notwithstanding)?

That push towards growth is real across both sides of the developer-administrator spectrum (I know many experienced developers struggling through React/Vue, ETL pipeline tools, or more devops than they'd prefer).

Across the board, it's partially fad and hype, but it's also because these workflows really are better. On the k8s side, a containerized architecture gives developers peace of mind in their local environments, makes you more provider-agnostic, and has the potential to scale more easily.

A sysadmin who can provide all of those is valuable, and deciding if that value is worth the learning curve is an individual decision. But to whatever extent the "resume-driven-development" aspect of container orchestration hype is distorting the market, it does seem to be in service of a better (if more complicated) toolset.

In this case I'm entirely upset by the former, and will leave the discussion of potentially inappropriate marketing tactics for another day.

You're right that bandwidth caps aren't my main complaint about ISPs, but overall displeasure with internet service is relevant to the bandwidth cap discussion because bandwidth caps are a feature that contributes to that displeasure.

Fairly or not, I blame ISPs for taking us from "A world where everyone pays $50/mo" to "A world where everyone pays $80/mo". Now they're trying to turn that world into a world where you have the choice between $100/mo and $150/mo. There's a fairness question to be discussed (I personally think it's not unreasonable to have society-wide, fast, affordable, unlimited internet be the default) but there's also a value decrease there that deserves just as much attention as the fairness question. That decrease (and not the fairness issue) is where my frustration is directed.

For me it's not a framing issue. I get upset by that sentence the minute the total receipt goes above $80/mo.

Unlimited internet has been a welcome respite from the inconsistent and unfair pricing of mobile data plans. Seeing that change without an explanation feels wrong.

I can imagine ISPs responding with "Here's your explanation: our infrastructure isn't built out to have everyone downloading 1TB/mo and if you want that you need to pay for it"

To whatever extent that's true, it's because of an ISP oligopoly and active lobbying measures that prevent creative solutions that might improve quality/decrease costs.

So I'm personally upset over this because it's a nickel-and-diming false choice between paying even more than our already-overpriced bills, or watching your quality of service decrease because a greedy company decided not to keep up with an eminently reasonable change in standards of quality.

Alongside a host of other issues ("Don't use CDNs because they increase your complexity" is a wild idea coming from someone advocating bare metal boxes) I think there's a confusion of terms when it comes to "cloud"

I prefer renting virtual private servers from Digital Ocean (or, yes, EC2 instances) and configuring them myself. Doing so is perhaps more involved than buying into the AWS/GCP/Azure ecosystem, but I already know the tools involved, and I value the safeguard against vendor lock-in/buy-in enough to spend more time on them.

Those VPSs are "cloud" solutions in my opinion, and a happy medium between AWS and the author's unnecessarily-profanity-laden proposal that everyone should rent/buy metal. You can be "pro-cloud" and "anti-closed-cloud-ecosystem" at the same time.

Recognizing the right tool for the job landed you job security for the next two years (and you're deserve it!)

But it could have very easily gone the other way. If your website had complicated validation rules on multi-page forms (not unheard of in healthcare) the site would be better off for some basic state management interacting with a standardized authentication/authorization framework that you didn't have to write.

From what you're describing, it sounds like you did right by the client in this circumstance. But sometimes, it does have to be complicated. And in those circumstances, frameworks and javascript (unlike garbage) have an important place.

I think the reason developers in particular need to be cognizant of this (as opposed to "everyone doing no harm") is because of labor power.

There's a societal expectation that everyone provide for their family. If you're doing so through evil means (selling drugs, joining the mafia, sweeping floors as part of a genocidal political movement...) then you're in the moral wrong. But if you're sweeping floors for Goldman Sachs, no one could reasonably blame you for causing the financial crisis. Your contribution to an organization that falls somewhere juuuuust south of neutral is morally justifiable because you've gotta pay the bills.

But if you're the kind of developer we're talking about here, your ability to provide for your family is largely taken care of. Your decision to support an organization is no longer rooted in this socially-acceptable "gotta pay the bills" mentality, and instead about providing luxuries. That's also fine, but you now have to reckon with the fact that your contributions aren't in pursuit of helping pay the bills, and internally grapple with the morality of sending your kids to private school vs using your specialized, valuable skills to help modernize your neighborhood community center's tech stack (but at a much lower salary).

All people need to grapple with the tension between individual/family-level selfishness and societal well-being. But the relieved, privileged life that higher salaries afford also comes with an added moral obligation to evaluate how we spend our time.

Something something spiderman great power great responsibilities.

I'm currently working with a client that needed more capacity than I could offer, so they hired an offshore team to take on some contracting work. The offshore team has been professional, knowledgeable, and able to produce high-quality, well-tested, well-commented code.

The difference is that they're several times more expensive than the "bottom of the barrel" cheapest coders you can find in their country, while still being a bargain by US standards. Meanwhile I've worked with lowest-bid, US-based contractors in the past, and their work has been reliably bad.

So I'd put forward that the tendency to "cheap out" is the culprit behind poor quality, rather than outsourcing. Practically, the two often go hand-in-hand since the cheapest developers are often abroad, but the two needn't be conflated, and recognizing the nuance opens up the door to working with a high-quality, international pool of talent.

National Journal (Atlantic Media) | Senior Web Developer | Washington, DC | Onsite | https://nationaljournal.com

Tech Stack: We spend most of our time in Python/Django and Javascript. Our frontend is mostly jQuery but we're changing that now (we do a bit with both React and Vue). Other things we work with daily/semi-daily include Postgres, ElasticSearch, MongoDB, Neo4j, Pandas, and Less.

Company Description: National Journal serves government affairs professionals with the in­tel­li­gence and tools they need to save time, in­crease ef­fi­ciency, and de­liv­er suc­cess. With a focus on actionable research, insights, and custom content, National Journal keeps members informed about key movements in people, politics, and policy.

We're a small team with good people, solid work-life balance, and interesting problems to solve. A lot of the job involves building new functionality around vendor integrations (Salesforce, Marketo, Google Analytics) and ingesting third-party data (FEC, Wikidata, VoteSmart, KnowWho...), as well as building out custom pages and dashboards for the public-facing site and for our home-grown CMS.

https://atlanticmedia.applytojob.com/apply/ykSMNosZG7/Senior...

Is this right? (Disclaimer: I'm about halfway through the Rust book, so I'm just a bit above useless when it comes to Rust) but my understanding was that since WASM can't do DOM manipulation, you still need JS and something like Emscripten to call WASM code.

The data and business logic of your code can be written in a WASM-targeting language, but I don't think you could make a React/Vue/Angular-esque UI library (or even a jQuery clone) purely in Rust.

> Shopify is giving merchants an opportunity to differentiate themselves while bearing no risk if they fail.

In addition to this being a great position for Shopify, this is an amazing thing for merchants compared to Amazon's offering; it's the critical difference between "We'll sell your stuff" and "We'll empower you to easily sell your stuff" that leaves power and agency in the hands of individual companies.

Semi-related: For a really insightful conversation about Shopify, personal interactions, and running a good company, I highly recommended The Knowledge Project's interview with the company's CEO, Tobi Lütke: https://fs.blog/tobi-lutke/

A few online tutorials mention enabling DoH through about:config but my Firefox version doesn't have those settings.

This is what I had to do to enable DoH through Firefox preferences:

- Click the hamburger icon

- Go to preferences

- Scroll down to network settings and click settings

- Click "Enable DNS over HTTPS"

(By default, this uses Cloudflare as your DNS server, but that can be further configured if you want)

Speaking for myself (as an American), I’d find this problematic without a referendum of support from Puerto Rico.

Self-determination is important, and selling land with an entire culture and population based solely on a balance sheet seems shameful. That said, if the deal were mutually beneficial for Puerto Rico and the US (“We’ll invest heavily enough in PR to make them interested in approving the deal in a public referendum”) that would be fine.

National Journal (Atlantic Media) | Senior Web Developer | Washington, DC | Onsite | https://nationaljournal.com

Company Description: National Journal serves government affairs professionals with the in­tel­li­gence and tools they need to save time, in­crease ef­fi­ciency, and de­liv­er suc­cess. With a focus on actionable research, insights, and custom content, National Journal keeps members informed about key movements in people, politics, and policy.

Tech Stack: We spend most of our time in Python/Django and Javascript. Our frontend is mostly jQuery but we're planning to change that soon (we do a bit with both React and Vue, and would like to do more). Other things we work with daily/semi-daily include Postgres, ElasticSearch, MongoDB, Neo4j, Pandas, and Less.

We're a small team with good people, solid work-life balance, and interesting problems to solve. A lot of the job involves building new functionality around vendor integrations (Salesforce, Marketo, Google Analytics) and ingesting data from API providers (FEC, VoteSmart, KnowWho), as well as building out custom pages and dashboards for the public-facing site and for our home-grown CMS.

https://atlanticmedia.applytojob.com/apply/ykSMNosZG7/Senior...

It's definitely viable, but I'm not sure about it being the only way.

Netflix shows that there's an appetite towards paying for content, and HBO furthers the idea while demonstrating how that same approach can be much more profitable.

For journalism side, premium, niche publications like The Information putting bets on the idea that users are willing to pay a lot of money for content as long as it's much better and more useful than the free alternatives.