I think the technique is important to have in your vocabulary, but I think the examples given are a weak sell.
In the example given, I would have preferred to extract to a method—-what if I want to load the config from somewhere else? And perhaps the specific of strip comments itself could have been extracted to a more-semantically-aptly named post-processing method.
I see the argument that when extracted to a function, that you don’t need to go hunting for it. But if we look at the example with the block, I still see a bunch of detail about how to load the config, and then several lines using it. What’s more important in that context—-the specifics of the loading of config, or the specifics of how requests are formed using the loaded config?
The fact that you need to explain what’s happening with comments is a smell. Properly named variables and methods would obviate the need for the comments and would introduce semantic meaning thru names.
I think blocks are useful when you are referencing a lot of local variables and also have fairly localized meaning within the method. For example, you can write a block to capture a bunch of values for logging context—-then you can call that block in every log line to get a logging context based on current method state. It totally beats extracting a logging context method that consumes many variables and is unlikely to be reused outside of the calling method, and yet you get delayed evaluation and single point of definition for it.
So yes to the pattern, but needs a better example.
> what if I want to load the config from somewhere else?
There are DRY and WET principles. We can argue which one of them is better, but to move something used exactly once to a method just due to an anxiety you can need it again seems to me a little bit too much. I move things into functions that are called once, but iff it makes my code clearer. It can happen when code is already complicated and long.
The block allows you to localize the code, and refactoring it into a separate function will be trivial. You need not to check if all the variables are temporary, you just see the block, copy/paste it, add a function header, and then add function call at the place where the block was before. No thinking and no research is needed. Veni, vidi, vici.
> The fact that you need to explain what’s happening with comments is a smell.
It is an example for the article taken out of a context. You'd better comment it for the sake of your readers.
> I think blocks are useful when you are referencing a lot of local variables and also have fairly localized meaning within the method.
I do it each time I need a temporary variable. I hate variables that exist but are not used, they make it harder to read the code, you need to track temporaries through all the code to confirm that they are temporaries. So even if I have just two local variables (not "a lot of") and one of them is temporary, I'd probably localize the temporary one even further into its own block. What really matters is a code readability: if the function has just three lines, it doesn't matter, but it becomes really ugly if a lifetime of a variable overshoots its usefulness for 20 lines of a dense code.
The other thing is mutability/immutability: you can drop mutability when returning a value from a block. Mutability makes reasoning harder, so dropping it when you don't need it anymore is a noble deed. It can and will reduce the complexity of reading the code. You'll thank yourself many times later, when faced with necessity to reread your own code.
There is a code and there is the process of devising the code. You cannot understand the former without reverse engineering the latter. So, when you write code, the more of your intentions are encoded somehow in your code, the easier it will be to read your code. If you create temporary variables just to parse config with the final goal to get the parsed config in a variable, then you'd better encode it. You can add comments, like "we need to parse config and for that we need three temporary variables", or you can localize those three temporary variables in a block.
Engagement: make sure that every member of the team is either on the incident bridge or has dropped what they are doing to watch you diagnose the problem. The more eyes on the problem, the more awareness of the pain will be absorbed by all. If members need to leave to get food or put children to bed, tell them to order delivery and to ask their spouse to do their job. Demonstrate human touch by allowing them to turn off camera while they are eating.
Comprehensiveness: propose extreme, sweeping solutions, such as a lights-out restart of all services, shutting down all incoming requests, and restoring everything to yesterday's backup. This demonstrates that you are ready to address the problem in a maximally comprehensive way. If someone suggests a config change rollback, or a roll-forward patch, ask them why are gambling company time with localized changes, and ask them why are they willing to gamble company time on technical analysis?
Root Cause Analysis Meeting: spend the entire meeting time rehashing the events, pointing fingers and assigning blame. Be sure to mention how the incident could've been over sooner if you just restarted and rolled back every single thing. Be sure to demonstrate out-of-the-box thinking by discussing unrealistic grandiose solutions. When the time is up, run the meeting over by 30 minutes and force all to stay while realistic solution ideas are finally discussed in overtime. This makes it clear to the team that nothing is more important than this incident's RCA--their time surely is not. If someone asks to tap out to pick their kids up after school, remind them that they are making enough money to call them an Uber.
Alerting: be sure to identify anything remotely resembling leading indicators, and add Critical-level wake-you-up alerts with sensitive thresholds for those indicator. Database exceeding 50% CPU? Critical! Filesystem queue length exceeding 5? Critical! Heap usage over 50%? Critical! 100 errors in one minute on a 100000 requests per minute service? Critical! Single log line indicating DNS resolution failure anywhere in the system? Critical! (What if AWS's DNS is down again?) Service requests rate 10% higher than typical peak? Critical! If anyone objects to such critical alerts, ask them why do they want to be responsible for not preventing the next incident?
+1 I agree 100% use it everywhere and let LS/IDE infer it.
On top of that:
* Reduce refactoring overhead (a type can be evolved or substituted, if it duck types the same, the autos don't change)
* If using auto instead of explicit types makes your code unclear, it's not clear enough code to begin with. Improve the names of methods being called or variable names being assigned to.
I can see explicit types when you are shipping a library, as part of the API your library exposes. Then you want types to be explicit and changes to be explicit.
I would caution that microservices should be architected with technical concerns first—-being able to deploy independently is a valid technical concern too.
Doing it for organizational scaling can lead to insular vision with turf defensive attitude, as teams are rewarded on the individual service’s performance and not the complete product’s performance. Also refactoring services now means organizational refactoring, so the friction to refactor is massively increased.
I agree that patterns should be used where most appropriate, instead of blindly.
What pains me is that a language like “Cloud-Native” has been usurped to mean microservices. Did Twilio just stop having a “Cloud-Native” product due to shipping a monolith? According to CNCF, yes. According to reason, no.
* consisting of PRs merged since last release. (This is better than manually updating CHANGELOG. Do not allow direct commits to main w/o a PR.)
* internal audience is engineering, PMs, customer success & support, these do not leave the company.
* PRs can be examined for more context if needed. This is a good enough balance between noise & automation.
* If you use a working tracking system like JIRA or GitHub issues, join the PRs w/ the system to output priority and other labels (like Feature/Bug). This will help internal stakeholders quickly identify how important each line is. Sort by priority and/or group by labels.
External release notes:
* manually updated log of important changes, such as new features or other larger changes. These do not include all bug fixes.
* visible to customers.
* do not mention version numbers, only dates. You do not want to leak how often you release, or customers will start demanding release notes per version or dictating your release schedule.
When you fix bugs for customers, tell them what day/time the bug fix went live.
Obtaining set of PRs merged since last release is non-trivial, but doable.
Plus users are now defaulted to a faster, less deep GPT-5.2 Thinking mode called “Standard”, and you now have to manually select “Extended” to get back to previous deep thinking level for Plus users. Yet the 3K messages a week quota is the same regardless of thinking level. Also, the selection does not sync to mobile (you know, just not enough RAM in computers these days to persist a setting between web and mobile).
It’s about the social safety of transitioning. The paper you referenced is from the UK, which is famously a TERF island (trans-exclusionary radical feminists). In the TERF island, it’s much less safe to be a trans woman than a trans man. Adolescents can sense the risk of being a trans woman is much higher, so many trans women stay in the closet and don’t come out.
Because a decade ago marks when the American right decided to scapegoat transwomen after losing their previous scapegoat, gay people and marriage, to SCOTUS in 2015.
2015-2016 is when rhetoric online and globally shifted towards villainizing trans women that weren't on the public's radar before. This was exported to UK politics and has been an incredible political success.
If that is the cause, how does it explain both the sex ratio shift and the rapid increase in referrals starting from around 2011-2012 onwards? There were gender clinics across Europe reporting similar demographic changes in pediatric referrals. This precedes the political developments in the US that you mentioned.
Yes, because it's a selfish movement and damages acceptance of the rest of us in LGB. We are allowed to criticize it. Have you ever thought, people were tired of people making everything, their whole personalities, etc, about gender and how marginalized they are? Living in one of the most prosperous parts of the world. THAT is why we criticize it.
Please stop. HN is not a place for political/ideological battle, including about this topic. What HN is for is curious conversation, including about difficult topics, but the guidelines apply, particularly these ones:
Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
Please don't fulminate. Please don't sneer...
Eschew flamebait. Avoid generic tangents. Omit internet tropes.
Please don't use Hacker News for political or ideological battle. It tramples curiosity.
That’s a real shame. It seems like Pulumi is the only alternative for internal DSLs for IaaC? I always found HCL to be quite terrible, slowly becoming less painful, but not really refactoring-friendly.
Terraform CDK had promise as a blessed infrastructure-as-actual-code solution from the official maintainer of Terraform, so easier to sell internally rather than something from a new vendor like Pulumi. I feel sorry for those teams who have migrated to TF CDK.
In the example given, I would have preferred to extract to a method—-what if I want to load the config from somewhere else? And perhaps the specific of strip comments itself could have been extracted to a more-semantically-aptly named post-processing method.
I see the argument that when extracted to a function, that you don’t need to go hunting for it. But if we look at the example with the block, I still see a bunch of detail about how to load the config, and then several lines using it. What’s more important in that context—-the specifics of the loading of config, or the specifics of how requests are formed using the loaded config?
The fact that you need to explain what’s happening with comments is a smell. Properly named variables and methods would obviate the need for the comments and would introduce semantic meaning thru names.
I think blocks are useful when you are referencing a lot of local variables and also have fairly localized meaning within the method. For example, you can write a block to capture a bunch of values for logging context—-then you can call that block in every log line to get a logging context based on current method state. It totally beats extracting a logging context method that consumes many variables and is unlikely to be reused outside of the calling method, and yet you get delayed evaluation and single point of definition for it.
So yes to the pattern, but needs a better example.
reply