'Surge Capacity' Is Depleted – It's Why You Feel Awful - <AUTHOR> https://elemental.medium.com/your-surge-capacity-is-depleted-it-s-why-you-feel-awful-de285d542f4c <comment><USER3> This article doesn't know it but it's explaining to middle-class people what being poor is like.

<comment><USER4> When something is written so perfectly there is nothing else to say.

But comments with many replies seem to draw more attention so I will add to this:

I have taught in an area that is poor. The opioid epidemic piled on top of that poverty to ravage it further. Students came to school and would say they were going to their uncle's in the next town tonight. I would say oh that's nice, what will you do. They would say, take a shower. We don't have running water so we go there once a week.

Basic needs that anyone in the middle class like me take for granted become focal points every day for someone living in poverty.

Do I put $5 of gas in my car or buy food? My car broke down and I can't afford to fix it. My minimum wage job uses dynamic scheduling and they just said I have to come in. My friend who I texted to take me can't do it at this time. There's no public transportation. How do I get to work? And if I do, who is there when my kids get home from school?

It's an insidious cycle. You can't see 5 feet in front of you and the treadmill never stops running.

God, I hope people read your comment and the article.

<comment><USER4> Six months ago a poster here lamented that they were rejected by Google and Facebook. That it would take 2-3 years for them to make $250k. That everyone they see on IG is getting to go to Hawaii on offsites while their employer won't even pay to send them to a conference in Seattle.

It is the kind of thing I can understand. Everyone, at every income level has problems that are very real to them. At the same time, I look at their complaints in light of what someone in poverty deals with everyday and their complaints are pitiful.

<comment><USER5> _I look at their complaints in light of what someone in poverty deals with everyday and their complaints are pitiful._

I agree with the need for perspective. The well off really need to know what the rest of the world is like, so they make decisions that take their effects on others into account. The disadvantaged really need to know what the path to being well off looks like, so they can apply their voices and efforts to the places that will make a difference. I've been in that place where a rise in the price of ramen or gasoline could make it impossible to pay rent. I've also been fortunate to find myself in a much better place.

However, we don't gain much by forbidding any displeasure for all but the worst sufferers. Failing to get a job at FAANG doesn't magically move that money into the hands of people who desperately need it. Being set back in one's own fortunate life still sucks.

We all need empathy at times, nobody should have a monopoly on empathy. Mutual empathy builds bridges, monopolized empathy builds resentment.

<comment><USER6> You have a good point about empathy. No one wants to feel unseen, or like their problems don't matter. The real thing that is required is that people have (most importantly imho) the willingness and also the imagination to think about the difficulties others must face. No one's life is completely pain free, and we could sidetrack into some Buddhist thought based on that. But, objective differences remain. Someone can drown in 6 inches of water as well as by falling off a boat in the middle of the ocean, and be just as dead, but it takes _a lot more work_ to get out of the middle of the ocean.

I think that people need to feel a sense of agency, self control, and meaning. That sometimes means they feel the need to greatly downplay the role of good fortune in their current life circumstances, and play up the mistakes of others to explain others' situations. It's an extremely common cognitive distortion, and it causes a real sickness in society.

</comment></comment></comment></comment></comment><comment><USER7> I have been increasingly disinterested in daily tasks, etc as this pandemic has marched on. I have even been going out, accepting there are risks, but still I'm not able to shake the sort of melancholy. The first few months of the pandemic were incredibly stressful at my job due to a vendor going under due to COVID, and I still have not recovered.

Since then I've been seeing more and more of my friends or former coworkers being laid off from their jobs, the growing social unrest around the US, all while some of the richest people I know are doing better than ever. I think for me, the feeling is brought on wondering if this pandemic has put me further behind, after I've already been effected by the 2007-2008 crisis. It really does feel, maybe for the first time (for me,) that the divide between those that can take advantage of this situation and those that cannot has grown into an insurmountable chasm.

I'm not even doing terribly but feel very far from my goals...which now feel even more in jeopardy, so I can't even imagine how other people are feeling.

<comment><USER8> _> It really does feel, maybe for the first time (for me,) that the divide between those that can take advantage of this situation and those that cannot has grown into an insurmountable chasm._

I 100% feel this.

One of the most acutely tragic aspects of this pandemic is that it dramatically amplifies the inequalities already present. Other natural disasters—wars, hurricanes, etc.—destroy physical objects. That effectively increases equality because it is most harmful to those that have the most capital.

This pandemic leaves everyone's possessions and wealth alone and cuts off your ability to work. The people most likely to get it are those who don't have the wealth and power to insulate themselves from risk. And they are the ones least likely to have the healthcare required to survive.

It is a horrible, _horrible_ tragedy.

At the same time, I try not to think of this as insurmountable. Everything good about our current society was created by people living in a world less just than the one we have today. It was the people living in a United States where Blacks were enslaved who emancipated them. It was men who legally had all the power that finally granted women suffrage.

There will be many casualties and many people who don't get to experience better days. But at the national level, I have faith that we can overcome this and end up better than we are today.

<comment><USER9> > It is a horrible, horrible tragedy.

A tragedy is something no one could have prevented. This is outright cruelty, bordering on genocide (particularly given the ways predominantly-black and native communities have been treated during the pandemic).

This was foreseeable and preventable, and the group that is to blame for it is glaringly obvious.

<comment><USER8> The pandemic is a tragedy. The US federal government's response is a crime.

It's very much like Hurricane Katrina. The hurricane didn't kill thousands of New Orleanians. Almost all of them were alive after the hurricane had passed. It was the local and larger government's failure to handle it that led to such a widespread disaster.

</comment></comment></comment></comment><comment><USER10> One of the main ways I've found out of this is to just accept that taking certain calculated risks is worthwhile.

At the very beginning of lockdown, we decided that seeing or next door neighbors was acceptable. That was helpful.

In early July, we decided seeing our closest friends was acceptable.

We started going to a teeny tiny farmers market once a week just to see other people.

Basically, I think it's important to remember that we are all human, and humans need other humans.

<comment><USER11> Things have gotten riskier, but you have increased your exposure. There are certainly other factors involved: we know more about those risks and how to mitigate them, for instance. But, things have gotten riskier, not safer.

From the discussions I have had with people around me , justifying the same 'calculated risks', it's clear that they aren't actually making rational decisions as much as rationalizing their decisions; bargaining with their emotions and then sliding into complacency.

<comment> just-juan-post > it's clear that they aren't actually making rational decisions as much as > rationalizing their decisions

Because one does not reach the same conclusion as you does not make their conclusion automatically irrational.

A very large part of the online community is irrational indeed. Irrational about the true danger of the virus.

I am not scared of the virus. I am scared of how scared people are of it.

All children who died of Covid-19 were already seriously ill [https://www.thetimes.co.uk/article/all-children-who-died- of-...](https://www.thetimes.co.uk/article/all-children-who-died-of- covid-19-were-already-seriously-ill-jlxr8mkxq)

In Ireland: Median age of death is 84. 94% with underlying condition(s) [https://www.hpsc.ie/a-z/respiratory/coronavirus/novelcoronav...](https://www.hpsc.ie/a-z/respiratory/coronavirus/novelcoronavirus/casesinireland/epidemiologyofcovid-19inireland/COVID-19%20Daily%20epidemiology%20report%20\(NPHET\)%20v1.0_20200825%20-%20website.pdf)

54% of San Francisco storefronts have closed [https://www.sfgate.com/business/article/Half-of-all-San- Fran...](https://www.sfgate.com/business/article/Half-of-all-San-Francisco- storefronts-have-closed-15513726.php)

The lockdowns and doom seem 1000x more irrational to me.

<comment><USER12> bingo! I fear that people are encouraging and instilling agoraphobia.

There's unmeasurable effects of all this hysteria and confinement. And if the over-cautious lockdown side is going to assume worst-case scenarios of covid, let's assume worst-case scenarios for the cost and side-effects lockdown - <USER2> true worst-case is that the benefit is marginal and we suffer every drawback.

<comment><USER13> It's not clear that the current economic situation would be better if we let everyone out and suffered all the death and negative long term health outcomes that may still lurk in apparently benign cases.

<comment><USER12> I appreciate the side that has humility.

An ability to _entertain_ that they're wrong.

It should be clear to people that at pretty much every stage, people have missed the mark massively on predictions.

The experts haven't been too helpful and really seem to be even worse than no advice.

The US regulatory state stood in the way of states offering testing as quickly as possible.

It's been a bungled mess and "but Trump" is all too easy and convenient.

<comment><USER13> Which people, which mark, have been wrong? What's happening (excepting the stock market) all seems to be pretty in line with the expectations I had around April.

I also don't agree that the experts have been unhelpful, and strongly disagree that they have been worse than no advice. They have been fought at every turn by people who don't understand epidemiology.

I think it's pretty clear that if we had actually listened to the public health experts, we (in the US) would be in much better shape. Trump (who you brought up) bears some of this responsibility for doing something so stupid as to politicize masks. He bears more blame because he appears to interfere with and try to adjust the science messaging to fit his narrative, which serves to confuse people.

So no - the experts haven't been wrong. We've just not spent much time listening to them.

<comment><USER12> > They have been fought at every turn by people who don't understand > epidemiology.

Didn't Fauci discourage mask usage at the worst time to discourage mask usage?

Weren't the experts continuously downplaying the danger while Trump was shutting down flights?

Wasn't Pelosi, de Blasio and crew telling us to "hug asians" and jump on the subway?

I'm not claiming there's anyone who was right in this mess, but there's very little ground to say anyone managed this correctly or would have been better equipped.

The supposed Democratic utopias in this country (NJ and NYC) killed off the elderly. And people want Cuomo to run for president...

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> The brain fog is very real.

In my case, I actually like my job (a rarity for most, including myself), but my productivity has been driven down when it is reliant on concentration (like a technical task). Interestingly, it's a bit higher in social stuff like meetings.

I know a few people who are actually MORE productive. These are the perpetual- workaholic-anyway types. They've adapted by launching their consciousness into action. I admire those people, because my friends like this are actually very very successful (before and during this). Joe Rogan even says sometimes, he escapes the pain of consciousness by keeping himself busy.

</comment><comment><USER15> As a counterexample, I felt awful in March and April and feel much better now. Very little has changed about my day to day routine. I think different people handle these things differently. I don't seem to have experienced this "surge capacity" phenomenon.

I think it's because I'm a naturally very private, introverted person, and have a lot of practice with isolation already. So now that the initial fears and anxieties have subsided, I've settled into a comfortable routine.

It's not ideal, and I miss having the option to see people or go to events. But for me, things are more manageable now than they were early on, where I was filled with constant dread and anxiety.

<comment><USER10> We actually had sort of a sweet spot the the late spring / early summer where the worst case scenario had obviously not happened, but people were still not going back to seeing their regular friends / family.

During that time, we got to hang out with our neighbors almost daily. It was great.

Now everyone is back to work / family / etc.

Same neighborhood, same people, just they don't come out to play anymore.

</comment></comment><comment><USER16> For a long time during this pandemic, I felt what I can only describe as Weltschmerz [1], the same sense of melancholy brought about by the idea that the bad has overtaken the good, and we are trapped into the final death throes as a species.

1\. [https://en.m.wikipedia.org/wiki/Weltschmerz](https://en.m.wikipedia.org/wiki/Weltschmerz)

</comment><comment><USER17> Normally I get annoyed by these kinds of off topic comments but what the fuck, this is what the article looked like for _5 seconds_ on a hardwired 80mbps connection

[https://i.imgur.com/6Rw6kbe.png](https://i.imgur.com/6Rw6kbe.png)

How does it get this bad?

<comment><USER18> Atleast you were able to read the article after 5 seconds. This is what I get.

[https://i.imgur.com/XqKEvn3.png](https://i.imgur.com/XqKEvn3.png)

<comment><USER19> delete all your *medium.com cookies, or try incognito mode

<comment><USER20> Block cookies on medium.com. You'll never have to deal with login/payment prompts again. (In the past, it has responses though, but the sidebar still works now.)

EDIT: I block cookies on many news sites as well. It bypasses paywalls on many sites (but not FT).

</comment></comment></comment></comment><comment><USER21> Related theory: [https://en.wikipedia.org/wiki/Ego_depletion](https://en.wikipedia.org/wiki/Ego_depletion)

</comment><comment><USER22> if you are like me and are out of reads on medium, there is an outline link [https://outline.com/GwHDSf](https://outline.com/GwHDSf)

</comment><comment><USER23> I don't feel awful.

<comment><USER10> I don't think I've ever felt "awful" except maybe the first couple weeks of lockdown.

But I have found myself randomly tearing up when listening to something or thinking of how things used to be.

I think I heard someplace describe it as grief. Makes sense I guess.

</comment></comment><comment><USER24> I think this will be a new normal. Now that we've seen the kind of surge capacity people are capable of we can push them to greater capacity than before and yield greater productivity.

<comment><USER25> I'm not sure where you're living and working where people are being _more productive_ the past several months, but it hasn't been something I've seen.</comment></comment>


Things are going so well we're doing a hiring freeze - <AUTHOR> https://m.signalvnoise.com/things-are-going-so-well-were-doing-a-hiring-freeze-5f66372a4214 <comment><USER2> Even if you don't read the article, you should read this story[0] that it links to. Which explains the mindset behind the decision. It's only like 200 words.

[0]: [http://renewablewealth.com/the-parable-of-the-mexican- fisher...](http://renewablewealth.com/the-parable-of-the-mexican-fisherman/)

<comment><USER3> I like the story but there's a glaring omission. Financial security. All you have to do to make the story fall apart is introduce a serious illness or handicap in his wife or kids.

<comment><USER4> but if you spend time in the village you build up a support network and its that support network that helps each other out in times of need. Sure if all the fish die they're still screwed but you can always find a reason to scare yourself into thinking you'll encounter the uncommon.

<comment><USER5> I have sympathy for this point of view, but unfortunately the most recent exposure I have to it is a local government deciding not to require Mennonite contractors to carry insurance, even though their competitors must. Apparently it's against their religion to imagine that the Lord would hurt a Mennonite on a jobsite badly enough that the community "support network" couldn't heal him themselves. I feel sorry for the poor bastard who won't get physical therapy and will be stuck in bed for the rest of his life. Maybe the support network _could_ afford the therapy, but he won't get it anyway, because Mennonite elders DGAF. I hope he'll be able to sue the cheap-ass property owner who bribed the city council to pass this stupid exception in the first place.

</comment></comment></comment></comment><comment><USER6> I would love to work at a company like Basecamp. Are there any other companies like them?

\- Less is more. Jason Fried is such a minimalist, [https://www.inc.com/magazine/20091101/the-way-i-work- jason-f...](https://www.inc.com/magazine/20091101/the-way-i-work-jason-fried- of-37signals.html)

\- Few formal meetings.

\- No full-time managers.

\- In fact, just about everything in their books Getting Real, [https://basecamp.com/books/getting-real](https://basecamp.com/books/getting- real), and Rework.

They do things that I've always felt are right but could not well argue. They are the opposite of most companies in so many ways, especially big corporations.

If you haven't read their books, you might tell me, just work at a start-up. But you really have to go through Getting Real to see how much they differ from everyone else, even your typical start-up. The chapter about doing less than your competition is particularly devastating, different than even most start-ups.

<comment><USER7> Why join? Start your own, run it like you want it to be run, and not only will you have the reward of working at a healthy place, you'll also have the reward of enabling dozens of employees to live fulfilling lives.

I like to think that Jason Fried/DHH went to the bother of writing all these books and blog posts because they legitimately want to see more businesses run like theirs in the world.

<comment><USER8> Because, to be perfectly honest, most of us don't want to start our own companies. I know for me, personally, that there's a whole lot of extra stuff that comes with running a company, stuff that I have absolutely zero interest in doing, that I would be required to do if I wanted my company to succeed. Second, I also don't really have any good ideas for what the company would do.

<comment><USER9> Surely if you had a good idea for a company, the currently zero interest stuff would suddenly become a bit more interesting. Then it would seem that this is more about the lack of any good ideas than the actual starting of a company.

<comment><USER10> If I have a good idea, it will be for a technical solution to someone's problem. I'll get excited about building that solution...but running the company and all the crap that it involves sounds like hell to me. A necessary evil. The "zero interest stuff" suddenly turns into the "deeply dreaded stuff".

</comment></comment></comment></comment></comment><comment><USER11> Per the parable, there is a altered version in which the business man, sensing the fisher man is not open to ventures, strikes up a similar conversation with another fisherman who does agrees to expand fishing to better provide for his family and community.

As a result the original fisherman finds his fish stocks are sapped by the growing fisher man's venture, and, unable to afford a boat to go into deeper water, finds himself bankrupt and working for the businessman who would have been his partner.

The issue with that version is it ignores that you aren't just sitting on your hands but rather ensuring that your customers stay your customers. But it does beg the question - Are you growing to a better future or just improving the same day over and over?

<comment><USER12> It sort of seems to me that the story continues to have a clear villain, the business man, and a clear victim, the other fisherman who will spend 20 years scaling before he gets back to the life he wanted—and so the right plan is for the original fisherman to treat the businessman and his American ideas as a threat to the community. Tell the other fishermen that if they go along with the businessman's plan to destroy the community and sell it to American interests, they'll be excommunicated from the village and their original business will be dead long before the businessman returns with lawyers. But if they change their minds, they'll be welcomed back with open arms.

<comment><USER11> Well, you can always modify it as the fisherman being unable to compete with the influx of capital to a competitor and ends up having to work for them.

That the community would be hit by a natural disaster but the prospering fisherman provides the influx of cash for emergency relief whereas doing nothing meant no means of recovery.

The story of preservation/destruction of habitat, the community improving/declining, the prospering fisherman rising but still (not) finding time to enjoy chatting with friends, and other dramatic flairs to help sell whatever flavor of capitalism you believe in.

</comment></comment></comment><comment><USER13> I really like their approach but I want to comment on the Mexican Fisherman story.

Neither the fisherman nor the banker have it right. You see, the banker may be overly ambitious, but the fisherman is not taking precaution against future's uncertainty. You can be sure DHH has enough money and he doesn't need the headache of running a big business. The fisherman, on the other hand, may want to consider the day he cannot fish and not expect the seas to provide until his very last day.

<comment><USER14> The Mexican fisherman leans on his family and friends, his community, when he runs into trouble.

The banker relies on a socialized bailout.

<comment><USER15> The fisherman feels shame and regret for having to turn to friends and family. Especially now his community is struggling as a result of having to bail out the finance sector.

The banker is happy to be getting on with business as usual.

<comment><USER16> Sad but true

</comment></comment></comment></comment><comment><USER17> It's insane how making a profit seems to considered "uncool" in the business world. Basecamp and particularly Jason Fried's writings (I realize this is particular article is by DHH) are super inspirational. I wish that building a solid, profitable business as opposed to being so focused on growth and finding more investors was more of the norm.

I want to work at Basecamp even more now, haha.

<comment><USER18> I doubt that anyone on the business side considers it uncool to build a small but profitable company. It's definitely cooler than having a VC shove you along the path to an acquisition by BigCorp Ltd.

Engineers sometimes consider those companies uncool, but that's just because they usually can't pay market rate for the best engineers.

<comment><USER17> I just mean it seems to be the path-more-taken. I'm basing it on my limited experience and my reading about running a business (which a did a bunch of but certainly never did an in depth study). A lot of companies I look at while looking for employment either want to sell or trying to grow to a mammoth size. Don't get me wrong--there is nothing wrong with that! It's just that I personally prefer to take the paycut and work for companies whose owners are slowly building a lifestyle and tightly knit team and wish I would see more of that pop up in job listings.

<comment><USER19> Its definitely not. VC funded startups are 0.1% of the global businesses out there. For every VC company there are 100k small businesses working on being productive and profitable.

<comment><USER17> I'm talking profit _focused_ vs growth focused. Guess that wasn't very clear. Obviously making a profit is somewhere on 100% of every company's agenda.

</comment></comment></comment></comment></comment><comment><USER20> Controversial opinion incoming, but I've found their writings less valuable over time and see them more as opinions with an elitist tone. This is coming from someone who owns a copy of Rework and might just go over it again for it's unique quality of life advice.

Lately I've really noticed that you don't just get advice anymore, you also get a little bit of commentary on how the rest of the tech industry is dumb or insane or both because those fools are doing it the old way and we're doing it our own progressive and enlightened way that we figured out on our own after we sat down, put on our critical thinking caps, and tried something different, and lo and behold it worked.

This latest exercise stands out as particularly offensive because there really isn't any advice or wisdom worth sharing. They're just telling us that Basecamp had the best year ever and they don't feel like improving on it so they're not hiring at the moment. Correction, it's actually a hiring freeze. Same thing, except the phrase "hiring freeze" is normally used in the context of something bad. They're going to use it in a different context to, you know, get more claps on Medium. On top of all this they felt the need to do a little compare and contrast between what they're doing vs what the rest of those unenlightened fools in the tech industry are doing, i.e. reinvest profits into new ways to grow.

Whatever. There are plenty of businesses that are happy with where they're at and settle-in, Basecamp is different because they're a tech company and they feel the need to blog about it. As for those companies that are growing, well, I think it's perfectly fine to keep growing, just don't turn your company into the equivalent of foie gras.

It's just disappointing. I looked up to them, still kinda do, but this is just marketing spin designed to make something boring and innocuous look radical.

<comment><USER21> If this were a Medium post, I'd give you lots of claps.

And I'd highlight this...

> They're just telling us that Basecamp had the best year ever and they don't > feel like improving on it so they're not hiring at the moment.

And...

> There are plenty of businesses that are happy with where they're at and > settle-in, Basecamp is different because they're a tech company and they > feel the need to blog about it.

I do enjoy their approach, quite a lot actually. But I'd enjoy it more if they spent more time sharing real experience and learnings (and failures), and less time projecting often absurd things on mainstream "entrepreneurial culture" while telling me how they're so much better.

</comment></comment><comment><USER22> Congratulations. You've figured out how to make me want to apply to your company! In the same way that I will never stop wanting to move to Norway, since they don't want me, I will now forever desire to work for Basecamp... I am so easily manipulated.

<comment><USER23> Getting into Norway doesn't seem too hard - but I'm open to be told why I'm wrong.

Here is what I found: "Broadly speaking, the award of a residence permit depends on two things: your country of citizenship and your ability to financially sustain yourself and any dependents. This generally means you need a job offer, or you must prove financial sustainability if you are coming to Norway to study or for some other reason.

It is possible for some people to move to Norway as a job seeker, but this is only allowed for a relatively short period of time. If you don't manage to find employment during that time, you will have to leave the country, and there is a waiting period before you will be able to return." \- [https://www.lifeinnorway.net/norway-immigration- guide/](https://www.lifeinnorway.net/norway-immigration-guide/)

<comment><USER22> Interesting. I just recall reading an article that went on about how your best chance of getting in is to marry in, which is unlikely for myself as I'm happily married already!

There was never anything specific about Norway (as compared to the other Scandinavian countries that generally top happiness indexes and such) just that the article said that I _couldn't_ live there.

<comment><USER23> Stackoverflow careers often list a number of jobs close to where I work in Oslo.

It seems to me if one gets a real job offer then there is a good chance to get a work permit.

</comment></comment></comment></comment><comment><USER24> The only thing novel here is the blogging/marketing. Lots of profitable companies don't hire when they don't need to - they don't brand it a "hiring freeze", blog about it and have strangers fawn over the concept.

</comment><comment><USER25> While I love their philosophy, part of me can't shake the feeling they are rubbing it in our faces for marketing purposes.

<comment><USER26> It's a corporate blog. That's the entire purpose of it.

<comment><USER27> Plus, it's hosted by Medium. The entire modus operandi of tech Medium is shameless self-promotion.

</comment></comment></comment><comment><USER28> It's notable that Amazon, despite record growth, is also in a hiring freeze for nearly the entire Retail business. Leadership is also simplifying the management chain to reduce bureaucracy.

</comment><comment><USER29> They are stopping at the lower end of Dunbar's number.

Smart guys.

</comment><comment><USER30> Just a question, I don't use Basecamp or similar products-- does Basecamp have competitors who are great at product and execution and who are pouring more resources and time and focus (like, where the team doesn't split their time between their product and a major OSS project like ROR) into their offerings? Is there no such competitor that has a better product that poses a threat to Basecamp's retention of users?

</comment><comment><USER31> Amidst the craziness that is the startup battlefield, its always a breath of fresh air to hear from the Basecamp founders. I feel more people should take this realistic approach to starting and running companies, and stop putting their life's work on 17 red.

</comment><comment><USER32> Anything larger than ~50 people and it becomes harder to maintain the company culture. Kudos to them for recognizing that they're happy where they're at.

</comment><comment><USER33> Who will be the first to hack into this now unhireable fortress and get a job with them? They have just made getting hired there a quest for every rails developer in the world. Changing the hiring and recruiting process, turning it on its head.

</comment><comment><USER21> What do people who use Basecamp think of the product?

(This is a slightly reworded version of my initial question... Who uses Basecamp?)

</comment><comment><USER33> I gave them 11 claps. I've never done that before.

</comment><comment><USER34> Revenue?

</comment><comment> taw-an sure, but how do the employees feel about it? what happens when support work balloons but you have the same amount of staff?

this is just an excuse to extract more profits coated in technofounderbabble.

<comment><USER35> If support volume grows, there are three options: 1.) hire more staff 2.) keep staffing levels the same and force workers to take on more for the same pay or 3.) look at why support volume is growing and a) fix some avoidable reasons that require support ( small fixes in UX can go a long way ) , b) automatically solve some of the support issues ( improved documentation ), and c) have the support staff build themselves better tools so they can more efficiently handle the support volume rise.

If you are an owner, #3 will not only improve your products, but also likely to make your entire company much more valuable over time. If the staff are also owners or there is a system in place such that the staff benefits when the owners benefit, they will likely be on board for #3 as well. If #3 is not sufficient enough to provide support, then hiring should be done.

<comment><USER36> There is another option: Raise prices.</comment></comment></comment>


What are some updated rails guide/book - <AUTHOR>

Ive been trying to teach myself rails through agile web development 4 book, but i started to run into errors at the cart section..after doing a lot of searching people are saying that the new rails update wont work with the book anymore.
What are your recommendation for an updated book?
Thanks! <comment><AUTHOR> In addition, is it possible to downgrade without creating new app?</comment>


Ask HN:Feedback about my new blog - <AUTHOR>

Hey I just launched a new blog related to Growth Hack and Digital Marketing. I would like to receive some feedback about.
My first post is "How to develop a successfully startup marketing plan" Please opinions are welcome
www.jojogiuffra.com <comment><USER2> It's obvious that English is not your first language. There's plenty of grammatical errors - which are all easily correctable.

On the topic covered however, it's honestly too high level for me. The title made me think that there was going to be something like a checklist or something actionable that I could use - which was not the case. The entire post is just at a very high level - more a series of things to consider than ways to construct a startup marketing plan. And even among those things to consider, there is nothing unique in what you have said which has not already been said many times before by others.

So I think you need to think about what unique perspective you can bring when there are already so many other people blogging about the kinds of things you want to talk about (and doing it very well). One concrete way you can bring something different to the table is experiments you have tried and the results of those. That is the kind of thing that I think will build your credibility in the growth hacking/digital marketing space rather than just talking about the kinds of things everyone is saying/has already said.

I hope this feedback was constructive.

</comment><comment><USER3> _" Eternal student, trying to do the world a little be more open mind. Right now I love all realted to strategic marketing, specialising at Growth Hack and Digital Marketing Strategies."_

I would write this as:

Eternal student, trying to make the world a little more open minded. Right now I love everything related to strategic marketing, specializing in Growth Hacking and Digital Marketing Strategies.

</comment><comment><USER4> Like ASquare said, it's obvious English is not your first language. If you want to keep your readers engaged and coming back, attempt to have native english speakers proofread through your writings first before publishing. You might want to look into Grammarly.com I've never used it before, but I think it might help your particular case.</comment>


Early numbers show surprisingly high iPad browser share - <AUTHOR> http://arstechnica.com/apple/news/2010/04/early-numbers-show-surprisingly-high-ipad-browser-share.ars <comment><USER2> The iPad browser share is 0.03%.

iPhone has 0.51%, BlackBerry 0.04% and Android 0.07%.

The graphic in the article doesn't have any percentages (!) and the article is kinda hard to skim down, so here's the raw numbers.

<comment><USER3> The article is quite short, but those of you who choose not to read it should know the actual numbers quoted:

The iPhone's share is 0.51% (not 0.051%), the iPod Touch has 0.11%, and the iPad has 0.03%.

That means iPhone OS has a total of 0.65%, Android and Windows Mobile each have 0.07% (not 0.05%), and Blackberry has 0.04%.

<comment><USER2> My bad, it's corrected now.

</comment></comment></comment><comment><USER4> This got me to check our stats and I'm surprised to see that of all our Safari visits, only 50% come from the Mac, with iPhone making up 25% and Android 14%. iPad is .4% right now.

</comment><comment><USER5> Surprisingly? What, people thought it could only be used to run approved apps?</comment>


Travelers Checks are so 1994 - <AUTHOR> http://paul.kedrosky.com/archives/2010/01/travelers_check.html

<comment><USER2> I'd like to see this correlated to any changes in US international travel. Without reference it's hard to tell what would be driving this.

I know personally, I used my debit card whenever overseas and I barely got charged. I know now I'm here in Canada that I can easily get an account that covers international debit transactions, but many also provide free travellers checks.

I believe travellers checks are still used as frequently as they are because of the insurance they provide on the money. Much easier to replace than dealing with credit card fraud with some of the institutions.</comment>


The Gravitational-Wave "Revolution" Is Underway - <AUTHOR> https://www.scientificamerican.com/article/the-gravitational-wave-revolution-is-underway/ <comment><USER2> > the distribution of the boring events is fascinating

This line needs to be made into a motivational poster, or a statistics meme.

<comment><USER3> "Boeing events are fascinating, for sufficiently large values of boring"

<comment><USER4> Airbus is stoked about that.

</comment></comment></comment><comment><USER5> I would recommend (as I've done before) Kip Thorn's book _Black Holes and Time Warps_ ([https://www.amazon.com/dp/0393312763](https://www.amazon.com/dp/0393312763)) to learn more about LIGO.

<comment><USER6> There's a lovely Sean Carrol podcast interview with Kip Thorne where he discusses the people and the work that led to the discovery.

[https://www.preposterousuniverse.com/podcast/2018/11/26/epis...](https://www.preposterousuniverse.com/podcast/2018/11/26/episode-24-kip- thorne-on-gravitational-waves-time-travel-and-interstellar/)

<comment><USER7> I can second this. The book is still worth getting too but this podcast is an excellent discussion around the subject.

</comment></comment></comment><comment><USER8> > Just as light can be bent and magnified when it passes through the > gravitational fields of galaxies and other massive objects, gravitational > waves should be warped in the same way, too.

I'm gonna need a refresher course on that.

<comment><USER9> Gravity propagates at the speed of light.

So, imagine you have a massive celestial body floating out in space, with a large gravitational field. Its gravitational field is always propagating. Now, take that celestial body, and make it completely and instantaneously disappear. There's now a gravitational differential between the now-gone body, and its previously propagated gravity field. You should be able to detect that if you're close, say through tidal differences.

Very similar happens with black holes colliding, except the gravity differential comes from the two black holes oscillating near each other, close to the speed of light.

Edit: this obviously isn't _exactly_ how this works, since it makes a lot of assumptions, such as the ability to instantaneously remove something. So, don't think of this as how "things actually work", but as a model to help build your intuition.

<comment><USER10> Be careful with that example. You probably know this, but stars can't disappear instantaneously, and so if you start with that assumption it's easy to get paradoxical results from relativity.

That doesn't mean there's anything wrong with the model. It's just GIGO.

<comment><USER11> A blackhole traveling at near light speed is pretty darned close to the analogy of a massive object instantaneously disappearing, similar to fictional spaceships engaging their warp engines.

Of course, it's not actually disappearing, just moving, but the original point was about detecting sharp changes in the gravitational waves. A quick Google search tells me that gravitational wave red shifting is a thing, and I imagine that with blackholes it's a very important phenomenon and area of study. And I would guess that there can also be interesting second-order effects that such a blackhole's movements have on the propagation of gravitational and electromagnetic waves from other objects.

<comment><USER12> > gravitational wave red shifting is a thing

Yes.

> with blackholes it's a very important phenomenon

Black holes can lense gravitational radiation emitted by background systems.

Most background systems we are likely to detect soon will involve black holes. But these are black holes in some sort of mutual orbit, rather than black holes simply moving across some system of celestial coordinates.

For black holes that are moving linearly at near the speed of light, the black hole's effect on the metric elongates like a pencil, with the field weak outside and growing strong towards the centre of the "lead" or graphite. This is similar to Lorentz-contracting the near region around the black hole, and one can generalize a bit and say that as the boost between an observer and any object increases, the object thins. In the ultra-ultrarelativistic limit, the object and all the strengthening-towards-infinity field values around it become infinitely thin.

As one's speed relative to a black hole gets very close to c, the black hole becomes quite easy to model as an exceptionally high-energy massless particle.

You get this effect when your small space capsule whizzes by our galaxy's central black hole at speeds near that of light too, and your small momentary perturbation basically affects the black hole not at all. Because Lorentz contraction is reciprocal, whizzing a black hole -- even a large one -- at ultrarelativistic speeds past the International Space Station is going to have very little effect on it.

We model this with the [https://en.wikipedia.org/wiki/Aichelburg%E2%80%93Sexl_ultrab...](https://en.wikipedia.org/wiki/Aichelburg%E2%80%93Sexl_ultraboost) metric of General Relativity and usually some gauge fixing and small perturbations.

Tossing a large black hole past the ISS at _low_ speeds compared to light will really mess up the neighbourhood of the solar system, but your space capsule can pretty safely manage a slow-compared-to-light hyperbolic orbit around a large black hole without much problem (ignoring any accretion disc and twin "paradox" issues).

</comment></comment></comment></comment></comment><comment><USER13> I recommend watching videos by Rana Adhikari if you want to know about gravitational waves. I went down a rabbit hole about a year ago with his video's, he is increasingly engaging. Also even in a short time his predictions for the field are coming to pass.

</comment><comment><USER14> The fundamental thing about gravitational waves is that those are a new form of data that the universe has always been sending towards us, and that we can read now. It's like being able to read the radio waves coming from the universe for the first time, not just the visible spectrum, or close to the visible spectrum.

If future advances in this field permit we may even use those to communicate. Who knows, perhaps someone is already talking in that language.

<comment><USER15> Quantum entanglement is much more feasible instead.

<comment><USER16> Quantum entanglement does not allow communication. This is known as the "no- communication theorem".

</comment></comment></comment><comment><USER17> I am a complete neophyte regarding these topics. I did notice that the detected events (black holes merging, neutron stars merging) seem really exotic, while I assume gravitational waves are all around us all the time. Is our instrumentation for detecting gravitational waves simply very insensitive compared to the instrumentation used to detect electromagnetic waves? Or are they harder to detect for some more fundamental reason?

<comment><USER18> As far as I understand it, the primary reason is that gravity is a _much_ weaker force than any of the others, so detecting gravitational effects is difficult unless the scale of the event is colossal. These instruments are extremely sensitive; the effects they detect are just that small.

<comment><USER19> It may be weak, but we can still measure it quite accurately:

"...Concluding on a lighter topic, let me remind the GGP community of what I recall as probably the most memorable moment of the first campaign. It occurred at the GGP Workshop in Munsbach Castle, 1999, when Virtanen was describing the effect of snow cover on the residual gravity at Metsahovi. He showed a figure of gravity increasing by about 2 microgal over a 4-h period as men shoveled snow from the roof of the SG station, when a member of the audience asked why there was an interruption in the rise of gravity, Heikki said this was a 'tea break'..." D. Crossley, in Journal of Geodynamics 38/3-4 (2004), p. 234.

</comment></comment></comment><comment><USER20> Prof. Sabine Hossenfelder has an interesting blog post on LIGO [1] and a related HN thread [2].

[1] [https://backreaction.blogspot.com/2019/09/whats-up-with- ligo...](https://backreaction.blogspot.com/2019/09/whats-up-with-ligo.html)

[2] [https://news.ycombinator.com/item?id=20881986](https://news.ycombinator.com/item?id=20881986)

</comment><comment><USER21> A revolution would imply there has been a breakthrough that would potentially lead to new theory. However, as with most modern physics experimental breakthroughs, it seems gravitational waves provide just further support for existing theories (with a few minor exceptions.)

Not to say that this isn't exciting, but it seems long overdue for us to stumble upon something major that is unaccounted for.

<comment><USER22> It's telescope 2.0. Not physics 2.0.

</comment></comment><comment><USER5> Btw -- _everyone_ should see the new documentary Chasing Einstein! I just got out of the theater and was BLOWN AWAY.

</comment><comment><USER23> If gravity waves exist, does that mean we could theoretically produce a gravity wave laser?

<comment><USER24> Just having "waves" is not enough for a laser. You need bosons--i.e., quantum particles with integer spin. To see the quantum aspects of gravitational waves that would correspond to this, you would need extremely strong sources--much stronger even than the black hole mergers that LIGO has observed. Nobody has any expectation of observing any quantum aspect of gravitational waves in the foreseeable future, much less being able to control such sources in order to make a laser.

</comment></comment><comment><USER25> This is giving me chills after reading Dark Forest. I hope this sparks a new era of SETI with gravitational waves as the medium. I believe a civilization advanced enough would use gravitational waves for communication.

<comment><USER26> What are the advantages of using gravitational waves for communication? They seem incredibly difficult to produce or detect, and don't travel any faster in a vacuum than electromagnetic waves.

<comment><USER25> Because gravitational waves get "dimmer" inversely with distance, while electromagnetic waves get dimmer inversely with the square of the distance.

<comment><USER27> No, both gravitational waves and electromagnetic waves decrease in intensity with the square of distance.

(This is true of any wave in 3D space, because the area covered by a wavefront increases with the square of distance. The inverse square law is a consequence of conservation of energy.)

<comment><USER25> The energy of the gravitational waves will decrease with the square of the distance, but the amplitude will not. We can detect this in LIGO. This amplitude is also known as "strain". For more discussion check this page: [http://spiff.rit.edu/classes/ast613/lectures/grav_i/grav_i.h...](http://spiff.rit.edu/classes/ast613/lectures/grav_i/grav_i.html)

The equation for strain is: [http://spiff.rit.edu/classes/ast613/lectures/grav_i/eqn_stra...](http://spiff.rit.edu/classes/ast613/lectures/grav_i/eqn_strain.png)

<comment><USER28> The same is true of electromagnetic waves. The amplitude of EM waves decreases inversely with distance, and the energy decreases with the inverse square.

Your original comparison of EM waves to gravitational waves is only possible because you looked at the power of one, and the amplitude of the other. If you compare apples to apples, they're the same.

<comment><USER29> A question for typon: in light of this information, do you still believe that advanced enough civilizations would use gravitational waves for communication?

</comment></comment></comment></comment></comment></comment></comment><comment><USER30> I really enjoyed this account of the technical aspects of LIGO

The Technical Challenges of Measuring Gravitational Waves – Rana Adhikari of LIGO

[https://blog.ycombinator.com/the-technical-challenges-of- mea...](https://blog.ycombinator.com/the-technical-challenges-of-measuring- gravitational-waves-rana-adhikari-of-ligo/)

</comment><comment><USER31> > Within those, 20 have been black hole mergers, two have been neutron star > mergers

And here I am on a blue planet, surfing the web.

</comment><comment><USER32> The high-frequency gravity wave revolution has been especially interesting. Keep an open mind.

</comment><comment><USER33> Unlike Electromagnetism, gravitation is boring because it is only a positive quantity. If you had positive and negative you could have maxwell's equations for gravitation and gravitational circuits and conductors and stuff.

<comment><USER34> Maxwell's equations for gravitation otherwise known as the Einstein Field Equation(s) .

</comment></comment><comment><USER35> Summary: "everything is going well"

<comment><USER36> Well that's a relief.

</comment></comment><comment><USER37> They're listening on a really noise channel. It seems premature to talk about the frequency of the detected events matching some expected rate when they keep tuning their filters to the expectations.

I recently read an article deploring the missing confirmation of the mergers through light-based astronomy. I can't find the article now, so I'm just going to list another one: [https://www.newscientist.com/article/mg24032022-600-exclusiv...](https://www.newscientist.com/article/mg24032022-600-exclusive- grave-doubts-over-ligos-discovery-of-gravitational-waves/) Has anything changed from what is described in the article?

<comment><USER38> There has been confirmation, I don't know why that article doesn't bother to mention it. [https://en.wikipedia.org/wiki/GW170817](https://en.wikipedia.org/wiki/GW170817)

<comment><USER37> The article does mention the 17. August 2017 event just not under the GW170817 name. From the article:

> They point out that the collaboration initially registered the event as a > false alarm because it coincided with what's known as a "glitch".</comment></comment></comment>


Remind HN: Chrome 57 Doesn't Trust StartCom or WoSign - <AUTHOR> TL;DR: If you still have StartCom or WoSign certs, you should update them yesterday.
Chrome 57 now reports the big scary "Your connection is not private" message for most StartCom or WoSign sites. This includes, "Attackers might be trying to steal your information," with the code NET::ERR_CERT_AUTHORITY_INVALID.
Even if users click Advanced→Proceed... to continue anyway, any cross-domain StartCom/WoSign requests will simply fail with net::ERR_INSECURE_RESPONSE (status 0).
In Chrome 56, this only applied to certificates issued after Oct 21, 2016, but starting in Chrome 57, it applies to all sites that are not part of the Alexa 1M, regardless of when the certificate was issued.
Unfortunately, it's not part of the Chrome release notes. The best resource I found on the issue was at https://forums.whirlpool.net.au/archive/2605051. It refers to this commit:

    commit	e719fc626a3b9a528bf226b704785bcb24d07868
    author	Ryan Sleevi <firstname.lastname@example.com>	Fri Jan 27 21:14:49 2017
    committer	Ryan Sleevi <email@example.com>	Fri Jan 27 21:14:49 2017
    Restrict the set of WoSign/StartCom certs to the Alexa Top 1M
    Restrict the set of domains for which WoSign/StartCom certificates
    are trusted to the set of domains intersecting the Alexa Top 1M
    whose certificates are unexpired and unrevoked.
    BUG=685826
 If you've been putting off your updates since the earlier discussions[1][2][3][4][5], then it's time to kick it into high gear and update your certs.
If you missed all that, https://wiki.mozilla.org/CA:WoSign_Issues enumerates the issues, and https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html summarizes it at a high level.

    [1] https://news.ycombinator.com/item?id=12389573
    [2] https://news.ycombinator.com/item?id=12444590
    [3] https://news.ycombinator.com/item?id=12617659
    [4] https://news.ycombinator.com/item?id=12787029
    [5] https://news.ycombinator.com/item?id=12841860
 <comment><AUTHOR> Clickable:

Best Chrome 57 resource I found: [https://forums.whirlpool.net.au/archive/2605051](https://forums.whirlpool.net.au/archive/2605051)

[https://wiki.mozilla.org/CA:WoSign_Issues](https://wiki.mozilla.org/CA:WoSign_Issues) enumerates the issues

[https://security.googleblog.com/2016/10/distrusting- wosign-a...](https://security.googleblog.com/2016/10/distrusting-wosign-and- startcom.html)

Past discussions:

[https://news.ycombinator.com/item?id=12389573](https://news.ycombinator.com/item?id=12389573)

[https://news.ycombinator.com/item?id=12444590](https://news.ycombinator.com/item?id=12444590)

[https://news.ycombinator.com/item?id=12617659](https://news.ycombinator.com/item?id=12617659)

[https://news.ycombinator.com/item?id=12787029](https://news.ycombinator.com/item?id=12787029)

[https://news.ycombinator.com/item?id=12841860](https://news.ycombinator.com/item?id=12841860)

</comment><comment><USER2> I faced the same problem. Reported a bug - [https://productforums.google.com/forum/#!topic/chrome/VeNiT3...](https://productforums.google.com/forum/#!topic/chrome/VeNiT3qtHG8;context- place=forum/chrome)</comment>


Elon musk's new website / venture is HTTPS self signed - <AUTHOR> https://x.com/?newpost=1 <comment><AUTHOR> Many of the media / tech blogs portrayed as x.com as new venture of Elon. Let's see what new rumor roundup we get after seeing the security error.

PS: Is appending a random query string is correct way of reposting a link on HN?</comment>


Building Domain Driven Microservices - <AUTHOR> https://medium.com/walmartlabs/building-domain-driven-microservices-af688aa1b1b8 <comment><USER2> Am I the only architect that hates microservices with gusto?

I've only seen bad implementations out there (tens of products), and have yet to encounter one that looks reasonable. If your average developer has trouble implementing something sane when the only problem is splitting data and functions locally into different components, why in the world would you assume that putting in a network layer, exponentially increasing the failure rates, loosing good stack traces, making refactorings that have to move data from one part of the architecture to another a pain in the butt (because requirements never change right?), etc... would be a good thing?

The horrors I've seen... oh boy, the horrors.

The people I've heard praising microservice architectures so far fall into two categories: (1) Ex developers that moved into management and read a few articles/bought a book on the subject and think it's a great idea (but have no actual practical experience) (2) developers that have just started working on a new one and are still in the honeymoon phase (mind you, not developers that have started working on an __existing__ one that is a few years old, those figure out the mess they are in pretty quickly).

You can screw up not-so-micro services too, but it's far easier to screw up microservice architectures and they are far, far harder to fix down the line when you figure out how you messed up (or re-architect when that thing that the PM told you was never going to be a use case is going to become a use case (after they tell you they are sorry of course)).

<comment><USER3> Totally agree - I'm not against services but I say as few services as humanly possible!

The issues with micro services are just so unbelievably large that it'd take too long to enumerate them here, but for me the largest issue is you are putting arbirary network partitions into your application and you CANNOT possibly know when these network partitions will suddenly make an operation you need to be atomic impossible (or at best eventually consistent).

In general it is excruciatingly difficult to iterate on micro services as well.

Then there is deployment, service mesh, k8s etc. etc. that you have to wrangle with, all because people refused to make bounded contexts in their application without making them into different services. It is much simpler to just design your monolith into separate contexts than it is to introduce all the error handling you need for network partitions.

I personally don't understand why Elixir isn't more loved by these micro services zealots - it allows you to get extremely far without adding network partitions and then allows you to switch to message passing when you need and then networked message passing all extremely smoothly as it makes sense for your app.

<comment><USER4> The best network layer is the memory controller of the CPU. Never breaks, no partitioning problems. If you really wnat for whatever reason uservices run it on one machine,

</comment></comment></comment><comment><USER5> Domain Driven Microservices looks good on paper, but its a very very terrible idea.

1\. You can't run join queries across domains

2\. You can't migrate your schema across domains

3\. You will need to sync and map a db with domain dbs for reporting

4\. You need to write api/client server for every domain and maintain this with db schema changes

<comment> UK-Al05 It seems like database schema and domain api are very coupled. They should have nothing to do with each other. You should be able to change your database schema without changing your api....

If you want to expose extra features or change the api design, you version your api.

Reporting is a problem, but most large business have some kind of datalake/datawarehouse where all of it comes together anyway these days.

<comment><USER6> > If you want to expose extra features or change the api design, you version > your api.

But you are still coupled. If you have to version your API that means it is relied on by something else and in order to use that extra feature still requires both (or more) services to all be on the same page.

Microservices let you deploy and maintain at different times (if that is appealing to you) but in order to realize a new business feature you are still coupled.

Now you have x tests for x versions as well, make sure the old version remains old and the new feature works in the new version.

<comment> UK-Al05 I mean yes, if you want a use a new feature using the new api. Then your going to have to move onto the new api. But that would happen regardless of using microservices.

If you version it though, services that don't care can cary on regardless.

</comment></comment></comment></comment><comment><USER7> I think that many people look at Microservices from a purely technical standpoint. How much compute power do I get per dollar spent. What about the monitoring complexities and the logging problems?

Microservices are actually often driven by business requirements. According to the Myhtical Man Month communication channels follow n(n − 1) / 2\. So a team of 4 developers has 6 possible communication channels, a team of 5 already 10. This eincreases sharply as team sizes increase and is one of the reasons big enterprise projects suffer compare to startups.

The business benefit of Microservices (done right) is that you build islands of communication, that communicate using only one outside channel. Now communication increases less sharply as teams are separated by their boundaries.

According to the guardian the team size and structure is one of the secret for Amazons success. [https://www.theguardian.com/technology/2018/apr/24/the- two-p...](https://www.theguardian.com/technology/2018/apr/24/the-two-pizza- rule-and-the-secret-of-amazons-success)

For smaller teams the communication benefit will often not outweigh the additional complexity.

<comment><USER8> You're making a point that Microservices help teams to solve the problem of increasing communication needs for larger teams. While your statement makes a lot of sense I'd like to ask why this problem cannot be solved with packages or classes within a monolith? A team can own a Microservice and expose an api to others the same way they could expose an api on a class or package, no? Microservices are a way of deploying small parts of software. It's not about communication across teams. It can help with communication but this is not only true for Microservices.

<comment><USER9> I believe it could be done via classes or packages, but only if the providers have the discipline to design it like a rest service, and the users then have the discipline to only use it like a rest service. Each package needs a small, consistent interface, with no way to interact except through that interface, with that same style of consistency across all libraries in the same way. The code must be isolated at runtime, so it can't steal resources from other pieces of code in the monolith or cause anything to crash. It can only respond to requests along the interface, either successfully or unsucessfully. So, theoretically possible, but in practice difficult once you add humans to the mix.

<comment><USER10> You can use ArchUnit[1] or similar frameworks to impose the constraints.

[1]: [https://www.archunit.org/](https://www.archunit.org/)

</comment></comment></comment></comment><comment><USER11> Bleah. I hate articles like this. They regurgitate all the well known talking points about enterprise software development but none of the realities of micro services. It sounds like they haven't actually worked in the trenches supporting and coding real microservices at scale.

The realities are that going from monolith to microservices is a huge investment, and only large engineering teams should do this migration.

The reason is that once you go microservices You instantly require an immediate investment in devops which is something you didn't need as much before with a monolith. Oncall rotations and pager duty schedules become imperative because services will go down. Also monitoring is another investment that you immediately need otherwise you're completely blind.

The article talks about things that are obvious, like designing the apis etc, but those are the same regardless of if it's a module within a monolith or a microservice. All the characteristics they list at the beginning is no different than what a team that owns a module in a monolith would require as well. It feels like this article isn't very useful because it regurgitates concepts from regular enterprise development and packages as new for microservices when it's not.

What the article lacks is the difference in architecting for a real microservice environment.

One of the biggest missed issues is never mentioning dependencies. Sure it's great to talk about how to model services with eventual consistency blah blah. But if you already have a large engineering team, which you must have otherwise why have microservices, then there will be a dependency between services and to believe otherwise is crazy. You will probably have one or two services that when they go down, your entire company is down. It's imperative that every service is architected with that in mind and what happens when it's down. Hand waving "eventual consistency" won't cut it in the real world, it's the biggest problem that each team needs to focus on early otherwise it's a ticking time bomb.

<comment><USER12> > Bleah. I hate articles like this. They regurgitate all the well known > talking points about enterprise software development but none of the > realities of micro services.

I disagree. The post is a good summary of all the key features and main concepts of a microservices architecture developed with domain-driven design. It does what it says on the tin, and you don't have to read three books to get there.

> It sounds like they haven't actually worked in the trenches supporting and > coding real microservices at scale.

I have no idea where you got that idea. It certainly wasn't from the blog post, though.

> The realities are that going from monolith to microservices is a huge > investment, and only large engineering teams should do this migration.

Your rant makes no sense at all. You're just mindlessly repeating cliches about issues that have absolutely nothing to do with the subject. I mean, the blog post is about microservices software architecture with domain-driven design and clean code, but here you are whining about how you believe refactoring projects designed following an entirely different architectural style is hard.

<comment><USER11> My point is everything they talk about is common to any type of enterprise software development. It's not new. And then they slap on "microservices" at the end so they can claim to have written something new.

If they want to write something new then talk about the realities of how microservice development is different than regular enterprise software development. Not regurgitating the same old concepts and pretending it's eye opening and new.

<comment><USER13> Um, it may not be new to you but it is new and eye opening to me and there might be hundreds or thousands of people who haven't read about this. From a newbie's POV, I quite like how the author explains the concepts with the example of an e-commerce company. Sure there will be advanced concepts but the author makes no claims that he is addressing that audience :) .

</comment></comment></comment></comment><comment><USER14> > _Hide implementation detail and expose functionality through intention- > revealing interfaces._

Except "REST APIs" (what microservices expose almost always) don't reveal anything most of the time, wanting to hide internal state behind a beautiful and uniform facade essentially representing a two-tier model. For example, orders and order line items can't be added/deleted at will, but depending on whether the order has been processed or not, should expose a "cancel" action (with partial refund/with penalty for cancelling), etc. Sure you can hide that behind a DELETE method, or "reify" a "cancelled" status, but why?

> _Services are resilient to failures._

In the case of "REST APIs", this means manually and labouriously attempting to reconcile state across multiple services in the client.

Compare this with state changes though ordinary RPC, which can expose a meaningful state model, give contextual diagnostics/exceptions, and can have transaction context flowing with RPC calls.

</comment><comment><USER15> I've been interested and confused about DDD, hexagonal architecture, clean architecture etc. for a couple of years now but unfortunately have not had time to dedicate towards reading up on all of them. Has anyone actually implemented any of this as part of their jobs? I guess it all depends what you do. I mainly do web stuff, and Django/DRF lets us go fast. Out of the box, I think this goes against the aforementioned architecture as the ORM couples the domain model with the data model. Besides, gathering requirements (at least at my company) is unfortunately an ongoing thing which is just the nature of a startup I suppose.

<comment><USER12> > Out of the box, I think this goes against the aforementioned architecture as > the ORM couples the domain model with the data model.

It doesn't. You're confusing the persistence model with the domain model. Your persistence model is dictated by your need to persist your data while meeting the requirements of your domain model. Your domain model does not care about your persistence requirements. Your persistence model is bounded to your persistence service and should not leak out, while your domain model is ubiquitous to your system.

Let's put it this way: with a Clean Architecture you are able to add/replace any persistence service you wish, and that has no impact on any other service.

<comment><USER15> Can you provide a concrete example? I would assume if you wanted to decouple the persistence model from the domain model then you would need to write a separate domain model in Django since the domain and persistence model are tightly coupled.

<comment><USER12> I'm not very familiar with Django thus my ability to provide relevant examples using this particular framework is limited.

However I direct your attention to the fact that Django docs make it very clear that to them in general each model maps to a single database table. That's quite Spartan even for an ORM, and obviously the point of a domain model is to model a problem domain, not to model the database.

</comment></comment></comment></comment><comment><USER16> I have done a lot of work with microservices, and I agree they come with a ton of cognitive overhead and new ways for things to fail in unexpected and painful ways.

In particular it now requires software engineers to understand principles and design patterns for distributed systems that when I was first starting out were relegated to theory and university papers. Can you guarantee ordering? Can you guarantee exactly once? How do you get transactional semantics? How do you handle cascading failures? It's all a bit overwhelming.

I have also seen however that monoliths at some point lock up an organization. The key measures of software delivery performance are deploy frequency, lead time from commit to running in production, mean time to recovery and change failure rate. Monoliths impact all of these when you engineering org starts scaling past a handful of teams. A monolith also becomes a single point of failure. One person in one team checks in bad code, and the whole system falls down. Microservices can give you resilience. You can also scale microservices independently - a CPU intensive service can get a bunch of pods, a memory intensive service gets a beefier memory allocation, and other services can run idle most of the time or even be deployed as FAAS functions that almost never run.

So I agree it's not a technical solution as much as it is about scaling an organization. At WeWork the team shrank so much that we began consolidating small services back into a single service because the operational overhead of having separate services didn't make sense any more when a single team was responsible for all of them.

I do think choosing to split out a new service is a big decision to make. You have to really think through the cost and benefits. You also need to make sure you have the right tools in place so you can detect and recover quickly.

Things like log aggregation, SLOs defined, measured and alerted on, canary deploys, progressive delivery, etc. Without that you're running completely blind.

I also think you want to be thoughtful about keeping your coupling low. If each service depends on twenty other services then in my mind you now just have a distributed monolith.

<comment><USER17> > Can you guarantee ordering? Can you guarantee exactly once? How do you get > transactional semantics? How do you handle cascading failures? It's all a > bit overwhelming.

I don't advocate DDD/microservices but if you absolutely must go down this road, Kafka Streams really neatly answers all these questions. Ben Stopford's book[0] and blog posts[1] are really great if you want to know more.

[0] [http://www.benstopford.com/2018/04/27/book-designing- event-d...](http://www.benstopford.com/2018/04/27/book-designing-event-driven- systems/)

[1] [https://www.confluent.io/blog/building-a-microservices- ecosy...](https://www.confluent.io/blog/building-a-microservices-ecosystem- with-kafka-streams-and-ksql/)

</comment></comment><comment><USER18> This talks about the thing that makes microservices fail most often, getting the bounded contexts wrong. It doesn't go into enough detail to show you how to do it right but does tell you what to watch for when you're doing it wrong.

The biggest, most common mistake is when a bounded context is called "<noun> service". This should be a huge red flag. Unfortunately, most books (and this post) always use this bad naming starting everyone down the bad path. At the very minimum call it a "<noun> management service" if it is the primary/general create/update activity. e.g you might have a checkout service that creates most orders and a order management service that can make drafts or adjustments. Order management (being the decoupled source of truth) might even be downstream from checkout service. Other services that need this information should get it's own copy asynchronously, i.e. decoupled.

The best way to learn how to do bounded contexts right is to study ones that worked well. Most writing tries to describe this in an abstract way using placeholder widget service things that helps no one.

The BFF pattern is good but doesn't solve everything. If you're accessing multiple services for a synchronous mutation, it's likely not highly reliable but can get by for an interactive service that can tolerate some errors. A messaging service is not one that should, they should always accept, store and forward with the lowest possible error rates.

</comment><comment><USER19> I might be a bit cynical / neckbeard, but the tech industry tends to go in circles with good engineering principles sold as the newest fads / hype. Before all the microservices craze it was REST and APIs, before that web services, SOA and ESBs, and before that XML-RPC / CORBA, EAI, and enterprise Java beans. And before that we had, we someone we had RPC over the network ('open systems').

Similarly DDD promotes separation of concerns and test driven development. That is exactly what eXtreme Programming told us in late 90ies when OOP and unit testing was in. Before that it was structured programming and software design specs, 4GL etc.

Bottom line is I wish people would start calling a spade a spade and indulge in less fads. Let's just call it structured programming over the network with clear separation of concerns and clean interfaces. That's good engineering. Test early and often. Write good documentation.

<comment><USER20> I'm completely on the same page with you on that one.

I understand though the marketing needs. IT has this steady influx of beginners that don't have the insight yet. Since there are so many of them, at any given time, it's reasonable (or maybe it _actually works_ ) to use standard advertising techniques at them. "Secret sauce", "The missing puzzle piece", "10 things that make you a better dev", "Dev done correctly".

Developers are kind of a dream target group: lots of disposable income, technically adept (i.e. at the cost of social skills), excited to experience a latest unicorn.

I'm seeing this whole "hype cycle" thing as a competition among more senior, adept in marketing, developers. Since there is such a high demand, the supply is also rich.

<comment><USER21> Could/should there be a 'wikipedia for software development practices'?

<comment> steve-s What about [https://wiki.c2.com](https://wiki.c2.com)

<comment><USER21> Something along exactly those same kind of lines of intent, yep.

A wiki-like reference guide that can assist architectural and technology selection recommendations.

Potentially with support for argument mapping[1] and decision trees[2] to deal with contentious or context-sensitive topics.

[1] - [https://en.arguman.org/](https://en.arguman.org/)

[2] - [https://en.wikipedia.org/wiki/Decision_tree](https://en.wikipedia.org/wiki/Decision_tree)

</comment></comment></comment></comment></comment><comment><USER22> Good article. This is what micro was built for. [https://go- micro.dev](https://go-micro.dev)

</comment><comment><USER23> Microservices are a good way to scale up development teams. So if you have 16 developers you can partition the work in two teams with one microservice each. If you have 80 devs you can have 10 teams with one microservice each team. Use Conwayś law to your advantage. Use DDD to decide where the boundaries are.

The advantage of having each team own a microservice is that each team can deploy their software independently from the rest of the teams. And it works as long as the APIs are honored. So Microservices are way to decouple the work of different teams allowing them to work independently from each other.

<comment><USER24> This only works for the simplest cases. If the two microservices must share data and direct calls (API calls) are not allowed (because they make your services highly coupled to each other to the point where if one of them ia down, then the other cannot work properly, or simply because your use case cannot tolerate the latency overhead) then each service must 1) replicate the data needed locally by listening to interesting events of the other service and b) emit interesting events so that the other service can update its local db. In other words, async communication.

While this let's you scale up teams, it's a huge overhead. So, unless you have over, let's say, 500 devs, it's not worth it.

<comment><USER23> > This only works for the simplest cases. If the two microservices must share > data and direct calls (API calls) are not allowed

Actually, one assumption is that the microservices don't share data. Only API (Rest, SOAP, GraphQL, etc) calls are allowed. And the boundaries are created minimizing the coupling between microservices.

> While this let's you scale up teams, it's a huge overhead. So, unless you > have over, let's say, 500 devs, it's not worth it.

As opposed to Monolith ? I think you will have problems collaborating in a Monolith at around 30 devs.

What I am opposing is the idea that you can have 30 devs and 50 microservices. Which I have seen in real life.

</comment></comment></comment><comment><USER25> Wow, microservices sound like a very painful trade-off to make. Is it really worth it?

<comment><USER26> Microservices are for when you have no other choice. If you truly cannot build a monolith, then build microservices. If you have merely chosen to adopt a microservice architecture when a monolith would have been suitable, then you have made a huge mistake.

</comment></comment><comment><USER27> This is pretty frequently discussed at Java developer conferences for some reason.

</comment><comment><USER28> I see the writer is from "WalmartLabs", so I assume this is advice for "Walmart scale" applications. For the rest of us it's probably good to remember that "you are not Walmart."

> Now, we know that in any modern application, sacrificing availability is not > a good idea either.

I feel like this will apply to less than 10% of applications. Normally you'd rather deal with the occasional downtime than dig through the fallout of broken attempts at distributed transactions. Ask yourself "What amount of $X,000 are we losing per minute of downtime" and see if it rounds down to zero.

> Another way to model this system is to separate, or group related models > into separate microservices. In DDD, these models — Price, Priced Items, and > Discounts — are called Aggregates.

And this must be the case for less than 1% of readers - it would take a massive system before I'd consider having prices and discounts in separate databases. You're taking on the overhead of writing an additional service for what could have been a database join.

</comment><comment><USER29> > Hide implementation detail and expose functionality through intention- > revealing interfaces.

Great, then a new US comes in that changes the intention and you enjoy the pleasure of changing the interface. Enter versioning. You start crying.

<comment><USER12> > Great, then a new US comes in that changes the intention and you enjoy the > pleasure of changing the interface.

That's not a microservices problem, not even a software architecture problem. That's at best a project management problem. In fact, pretty much every single engineering project there ever was would struggle to meet any form of neck- breaking change in design requirements.

<comment><USER30> But with microservices you have more supposed independent interfaces. With a more monolithic approach you might just change a system internally and deploy it. Internal interfaces are generally easy to adapt.

<comment><USER12> > But with microservices you have more supposed independent interfaces.

You don't. You have more services accessed over a network, and might not have control over all services. But that's already par for the course in nonoliths.

If you were to refactor your components by changing classes around (say, a major version update in a dependency) while not updating the components that used them then you would also have problems.

That's why versioning and service discovery and HATEOAS are a thing.

<comment><USER30> But the compiler will find that. It's very different from deploying services. (And I've been doing both, for years.)

</comment></comment></comment></comment></comment><comment><USER31> One of the problems with forcing strictly disparate domain/service is that each one introduces its own security context and authZ handling. That's a lot of places for mistakes.

<comment><USER12> You're just stating that distributed services need to have security.

<comment><USER32> I think they stated that distributed security is more work / harder than monolithic security. I would tend to agree.

<comment><USER33> In my experience, the reason it is more work is because you end up with something much more well defined and robust.

Each service having well scoped and defined RBAC or AuthZ for its focused set of features makes the whole architecture as a whole much easier to reason about from a security standpoint. I've done successful pen testing and auditing of some monoliths in my time where the critical security issues arose out of untested and unexpected execution paths that were only possible because the surface area is so large.

Maybe in theory a "well written" monolith would be superior but I'm only going but what I have seen in practice. I think the extra work is worth the trade off.

</comment></comment></comment></comment><comment><USER34> [https://outline.com/ws4FFC](https://outline.com/ws4FFC)

</comment><comment><USER35> I'm really having a hard time finding the willpower to read articles that just even mention "microservices" in the title after working on such architectures (with Java) for a while.

Nice idea but most of the times horribly implemented, with no care about monitoring and logging as someone has already said.

It requires a degree of attention to details during design and development that few are willing to put in. It's easy to go for a prepackaged solution/framework thinking that you are building something that could be considered state of the art, when instead you end up with something that takes multiple tries to even boot correctly or 10 minutes or so to "stabilize" a garbled mess of inter-dependant components.

Designing these systems require a whole new set of skills that were not required when designing monoliths.

<comment><USER36> You really point out that you're going to require a dedicated team to manage all the things you'll need. I you're not at this scale there will be a lot of overhead to manage for the dev teams.

I'm in a team like this, supporting a bunch of developers - we build a CLI, an API (in our domain! It's just another domain with the devs as consumers) and juggle approx. 16 different tools (monitoring, metrics, tracing, service discovery, etc etc).

Doing it through custom tooling that enforces conventions is, IMHO, the way to do it successfully.

<comment> jon-wood This is precisely what the team I lead is responsible for as well. We've got a set of standardised libraries, deployment conventions, and a CLI which encapsulate almost everything needed to have a service coexist within the wider platform in a consistent manner.

We're also responsible for wider reaching services within the platform such as an API gateway, authentication, and event ingestion from IoT devices. As the team that has an on-call rota we also give the final go/no-go on services going into production.

</comment></comment></comment><comment><USER37> Off topic but wanted to flag:

> [...] we intend to cover our experiences with Event Storming in a separate > blog.

In case anyone is not familiar with this usage, these days "blog" is often used instead of "blog post." I was thoroughly confused by this when I first ran into it. I tried fighting against this usage by colleagues, but it seems to be widespread enough now that it cannot be fought... I guess language evolves, and I have to get with the times.

I suspect one or more of the following aspects might be at play: • general loss of identity (since lots of posts are on medium, and less on a personal and work blogs) • "blog" is short for "blog post" • desire to distance oneself from "post" which is more associated with facebook and instagram posts

<comment><USER38> I don't read any more into it than someone saying "put it on the USB" instead of spelling out USB stick/drive/etc. It's just a lazy abbreviation that caught on.

</comment></comment><comment><USER39> anti-agile

<comment><USER40> That's a strange claim to make. Care to elaborate on how making things easier and faster to change is less agile?</comment></comment>


Getting Started with Swift on Android - <AUTHOR> https://github.com/apple/swift/blob/master/docs/Android.md <comment> V-2 "Getting Started with Swift on Android"

"FAQ [...]

Does this mean I can write Android applications in Swift?

No."

<comment><USER3> To clarify - you cannot currently write GUI applications for Android in Swift, because no UI toolkit exists for this task at the moment.

<comment> V-2 Well, thanks. I kind of figured it out, but still I believe it should be stated explicitly, because it looks quite confusing

<comment><USER4> Consider it's a _getting started_ , not a _develop android apps with swift_. Then it's explained in the FAQ, IMHO it makes sense.

<comment> V-2 Not explicitly, in the sense that it tells me what _can 't_ be done instead of what _can_

</comment></comment></comment></comment></comment><comment><USER5> I personaly hope Google will replace Java with Dart at some point - it will be easier to switch for average Java dev (syntax) and there is already Dart for Android project - <USER2>

<comment><USER6> Flutter is a very very very long way from being a replacement for the native UI kit though.

It is stuck in an uncanny valley where the effects sorta looks like those of the platform, but are different enough to make the discrepencies very visible.

A simple list skips a lot of frames on my Nexus 6P, I can't imagine what I will look like on the regular user's phone.

None of the samples do anything interesting, they are just very tiny fragments of UI and even then there are many things missing.

Bringing Flutter up to speed with the native UI toolkit would demand a titanic amount of work

</comment></comment><comment><USER7> Has anybody used Silver ? [http://www.elementscompiler.com/elements/silver/](http://www.elementscompiler.com/elements/silver/) It seems to offer a working Swift compiler which can also create android apps (and ios and .net)

<comment><USER8> I haven't used it yet, but intrigued by your comment I did a bit of research, and here's the gist of what I have understood: the company behind Silver is RemObjects, and they offer a cross-platform compiler suite called Elements, which supports three languages: C#, Oxygene (their own creation, apparently heavily influenced by Object Pascal) and now Silver, which is Swift with "a few features" added to bring it in line with the other two languages. They're trying to downplay the additions for obvious reasons, but they sound pretty hefty to me: Exception Handling, Partial/Static Classes, External/Inline Functions, Events etc. Imagine what Rob Pike would say if someone came along and added all that to Go ;) (see [https://docs.elementscompiler.com/](https://docs.elementscompiler.com/) and [https://docs.elementscompiler.com/Silver/LanguageExtensions/](https://docs.elementscompiler.com/Silver/LanguageExtensions/) for details).

That being said, the compiler (and IDE for Mac) are freely available, so you can try it out. RemObjects have been around for a while and I was pleased with their products back in the day when I was developing in Delphi, so I'm sure Elements is a solid product as well, just maybe not what you are expecting...

</comment></comment><comment><USER9> Is there a reason Google didn't make the UI framework language agnostic? Had they coded the Framework API in C/C++ they could easily have made any language a first class citizen by supplying the necessary API wrappers/facades for the languages that needed it.

<comment><USER10> They chose Java because it made sense at the time. Most mobile apps before the current smartphone era were Java based using j2me (or whatever it was called). Just like most iOS developers were existing Mac developers using Obj-C.

Still don't know why they don't have hooks for other languages. Your option is to use NDK (I think haven't coded for Android in ages) for those that insisted on C/++

<comment><USER9> I'm aware of why they selected Java (mindshare) for their development platform, but that doesn't exactly explain why they coded the majority of their framework in Java. Had they used C/C++ the interoperability with other languages for UI based applications would have been trivial with the respective API wrappers in place.

<comment><USER11> But they do, just those APIs aren't exposed to other NDK applications.

For example, the 2D rendering engine is implemented in Skia.

</comment></comment></comment></comment><comment><USER12> Android port has been merged into the swift code-base:

[https://github.com/apple/swift/pull/1442](https://github.com/apple/swift/pull/1442)

</comment><comment><USER13> Is it just 'Rumour' at this point Android will officially adopt Swift as their primary application development language?

<comment><USER6> Yes. There are probably internal discussions about the future of the platform, but we have no official information.

This 'android port of swift' only allows to target the NDK, not to build an Android app from A to Z.

</comment></comment><comment><USER14> This is exciting! I can only wonder if Oracle has been enough trouble to pester Google into using a language such as Swift.

</comment><comment> awinter-py I pity the fool JNI

</comment><comment><USER15> Would this work to create games for android with OpenGL?</comment>


How to sell nothing - <AUTHOR> http://www.cnn.com/2009/OPINION/11/17/sutherland.advertising.selling.intangibles/index.html

<comment><USER2> Is the guy at 2:37 sleeping?</comment>


'Don't Ground the Airplanes. Ground the Pilots.' - <AUTHOR> https://www.theatlantic.com/notes/2019/03/dont-ground-the-airplanes-ground-the-pilots/584941/ <comment><USER2> > the Max was grounded without any clear technical understanding. As such, > there is no clear technical path to follow in order to restore it to flying.

This is interesting and not being discussed enough. Those planes were all grounded because it's known that in a short space of time 2 have crashed (and a 3rd one didn't because there was an extra pilot who got some insights and knew what to do). But it's not known if all had the same problems.And with all discussion if the 737Max design was stretched too much while avoiding new training or certification, it won't be easy to Boeing to make people confident again that there are no more "new features" hidden somewhere.</comment>


MatzLisp - <AUTHOR> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/179642?matzlisp

<comment><USER2> This is a great quote to send on to a Java refugee hiding out programming Ruby.

They think they've found something that's "Java done right" when they've entered the LISP-zone.

</comment><comment><USER3> After you take out s-expressions and macros, what's left is no more Lisp. What really sets Lisp apart is the ability to _easily_ manipulate code programmatically.

<comment><USER4> S-expressions are not necessary to a LISP. The original language concept was supposed to use m-expressions (somewhat more C- or Algol-like), and s-expressions were an intermediary implementation measure.

Original LISPs didn't have the macro system everyone associates with Lisp, either.

. . . and Matz didn't do a very good job of removing macro capabilities, because Ruby's still halfway to CL on that score.

<comment><USER2> Actually, I think that Eric Kidd would disagree with you. He makes a great point here: [http://www.randomhacks.net/articles/2005/12/03/why-ruby- is-a...](http://www.randomhacks.net/articles/2005/12/03/why-ruby-is-an- acceptable-lisp) that "In particular, macros which actually compile mini- languages haven't appeared yet, although they might be possible with enough work."

One can fake a great deal of LISP in Ruby but, I would like to hear more about your thesis of "Ruby's halfway to CL" for no other reason than I've been spending free time "Ruby-fying" Scheme and see more of a gap than you're implying exists.

<comment><USER4> This is why I said "halfway". Ruby isn't a replacement for Common Lisp (or Scheme) in the macro department; it just gets close enough that you can see Common Lisp (or Scheme) from there.

Consider that, when speaking literally of getting halfway to something, you have exactly as far to go still as the distance you've already traveled. It's not like I said Ruby was _most_ of the way there, y'know.</comment></comment></comment></comment>