rvdginste

Yes, but you are referring to standalone scripts, not functions defined within a Bash script.

Compare for example the following helper code used for git command completion inside Bash and inside PowerShell.

Bash: https://github.com/git/git/blob/master/contrib/completion/gi... PowerShell: https://github.com/dahlbyk/posh-git/blob/master/src/GitPromp...

I believe this is clean Bash code and clean PowerShell code, and a script with a certain complexity. The functions inside the Bash script are documented using comments, the ones inside the PowerShell script are documented using "structured comments" (similar to javadoc/xmldoc/...). The parameters of the functions inside the PowerShell script also contain metadata which is used to provide completion on the commandline and similar functionality as the command line flags you demonstrated.

I just learned about 'getopts' in Bash, which you can actually also use to implement parameters to a Bash function. So what you are showing on a script level, can also be applied for functions. Did not know about that.

Still, not saying PowerShell is better than Bash in a Linux context, but it seems a lot of Linux users have a gut reaction to right out reject PowerShell. I think it does have some advantages for certain use cases, like more complex scripts, a cross-platform context, ... and of course, for someone with a .NET background it's easier to program more complex things with it.

What I had in mind, is a webapp that does backend api calls. That is a synchronous call, in the sense that often the user is waiting for it since it is often the result of an interaction with the website. I did not consider that a low latency requirement. Still, when a backend service (accessed either directly or indirectly) is not available or has problems, and there is a retry mechanism, this quickly runs into seconds.

> You don't add meaningless complexity for the sake of it after all. > You can decide where complexity lives after all.

Good points and something I should think about when designing systems.

You have good and interesting points, and it is true that I am very wary about introducing extra latency in the context of an http api that is used by a webapp. With the infra that is available today, it is possible to build snappy webapps, but my feeling is that you have to be wary about introducing extra "hops" in the execution of one http call, even though that is not strictly a "low latency" requirement.

I understand what this pattern does, but it makes me wonder how useful it is in practice. I am focusing specifically on the retry and circuit breaker functionality.

If the call is done in a synchronous context (for example original client executes a REST call), you are adding latency by inserting an extra service in between. When the remote service is not immediately available or responsive or fails, and you do a retry, in the end your call might take too long and the caller might cancel the request. I have seen this behavior in practice and it makes me wonder how useful this implementation is in a synchronous context. You add complexity (on the infra level) and you add latency in the happy path. When a retry is needed, most of the time (in my experience) the call to the remote service does not succeed in time, and the original call still fails.

If the call is done in an asynchronous context (for example the original client picks up a message from a queue and processes it), you are adding latency and complexity by inserting an extra service and extra logic. However, when the remote service is not immediately available, you can just let the processing of the message fail. The queue or bus should contain retry logic that could be finetuned based on the type of error you get. So, in that case, you should already have a retry mechanism out of the box, then is the added latency and complexity really worth it?

I understand about the circuit breaker, and I understand that might be useful, because it could prevent the remote service being overloaded with requests (well, at least if every caller to the remote service implements circuit breaker... but then, the ambassador service would better be placed on the side of the remote service and every client should be forced to pass through it, and then it might just be implemented inside the remote service instead of in a separate service adding extra latency/complexity/... basically, the remote service should protect itself against this).

Thoughts? Does it make sense what I am thinking?

> But it's buried very well under layers upon layers of deep integration with windows and .NET, the attempt to shoehorn a character-based shell into working with objects somehow, and a syntax that rivals enterprise java in its verbosity.

You do know it runs on Windows, Mac (amd64/arm64) and Linux(amd64/arm)? There is definitely integration with .net, which is available for the same platforms. The integration with .net is part of its power for me.

Verbosity can increase readability.

> Is it? Why? Man pages, infopages, and `apropos` all exist. Individual man pages may be bad, but the system as a whole is solid. It also isn't dependent on the shell. All these mechanisms are just normal programs that can be executed by any shell.

You will not loose those tools and their man pages when using PowerShell. He is referring to the documentation of all helper functions defined within PowerShell. When you create a helper function in Bash, how do you document it and what tool can you use to consult that documentation?

Bash does not have named parameters for its functions, let alone metadata on them…

I do not understand the "inconsistent" comment either. The "verbose" comment I can follow, but since you have tab-completion, it does not really matter that much.

The Get-Help command is super useful, with the option to show examples (-Examples).

Consistency is encouraged because every PowerShell command is the combination of a verb and a noun. The verbs are standardised and you can get a list of supported verbs using Get-Verb. Nouns are free to choose.

There is also Get-Command which gives you a list of available commands in your current shell. You can import modules in the shell which will give you access to extra commands. Get-Command supports the parameters Module, Verb and Noun to filter commands. This allows you to fairly easily discover commands that might be usefull to you.

The Get-Alias command will show you what aliases are defined in your shell. This can sometimes be confusing as some of the default aliases look like Linux/UNIX shell commands.

Creating a PowerShell module is also not that hard. When defining a PowerShell command, it is for example very easy to limit the values for a certain parameter and that in turn hooks in into the completion functionality. The completion functionality is available out-of-the-box for every PowerShell command available, including the ones that you create yourself.

My main OS is Linux, but I do work a lot with Windows systems (I develop in C#). I've used bash a lot, but I also learned PowerShell because that is simply the way to go on Windows systems. I like PowerShell, it has a lot of nice features and it is easy to work with. I find it a lot easier to program extra functionality in a PowerShell module compared to defining extra functions in bash. As a C# developer, PowerShell basically also gives me access to any C# class available by default in .NET. It is even simple to load a class from a third-party assembly, and even to compile C# code on the fly. In short, I can do whatever I want in PowerShell a lot easier than in Bash.

Note that that does not mean that I no longer use Bash. It depends. My default shell on linux is bash. When I need a one-liner to do something, I will first reach for bash. It is only when I need a longer script that I will reach for PowerShell. For example, I need to read a json file, manipulate the json structures and write the data back out. That is something I would do in PowerShell. For a build script that is simply a sequence of steps, I would go for bash, even if it involves the use of jq for json for example. And obviously on Windows, my default shell is PowerShell. Even though I have used cygwin/ming before, I would not do that if I can avoid it... there is really no need to try to run bash or anything else on Windows when you have PowerShell.

Been using Debian Linux as my main os for over 20 years. And happy that there’s less and less of a need to run a Windows vm.

But even though most people are not happy with the recent evolution of Windows, most people will complain and then use it anyway. And Microsoft will get away with it and will take another step with the next release…

I also run Debian on all of my machines, either Stable or Testing. It runs fine on older machines, at least up to Core 2 Duo (64-bit).

The advantage is that Debian has a very large package repository, is actively maintained (with security updates) and is often supported by externally packaged software.

I find these imprecise, rounded, relative timestamps very irritating and I am so happy to see that I am not the only one.

If you have the exact absolute data, then just give me that.. in its original form. Unbelievable that people put effort into making it less precise and making relative. Why? Because it looks _cute_? Personally, I always find it hard and tiring to mentally process these and map it back to an actual point in time.

> what package do I install to get this file my program is demanding?

You can install apt-file, and then use `apt-file search`.

> Socially this arrangement is kernel-like. The tech lead of the project runs the repo from which releases are done and merge in from teammates, which in turn can merge in from their teammates and so on. Ownership is always clear because the act of merging is also the act of taking responsibility. You can't get a tragedy of the commons where juniors keep picking other juniors to review their work like you can in more conventional free-for-alls.

I think the way you work is very interesting. We once discussed about having a process that is more kernel-like.

The fact that everyone has their own remote clone of the (or all) git repositories, does that not introduce overhead? We did that long time ago when we started with git, but thought it introduced extra overhead without any benefit. I assume you do it to make the ownership clear? And I also assume that everyone in your team is very comfortable with git? (yes, I do think developers should know their tools inside-out, but that is sadly rarely the case)

Can you explain in more detail the steps for a code review process? Is it the author that creates and deletes the review branch in the clone of the reviewer? How does the author know that the reviewer finished the review? Is it always the author who pushes his code to the technical lead for merge into master?

I have been thinking about this approach, because I heard other people doing exactly this.

I am using a pull request flow currently, but have some annoyances:

- I nearly always check out the branch to review (I use a separate worktree with git worktree for this) so that I can explore the code and changes using my IDE; it is annoying to have to switch back and forth between IDE and PR interface to add comments;

- Sometimes I want to do a global review of some part of the code. This is typically not supported out of the box with review systems based on PRs. Sometimes you can work around that by creating dummy branches, but it is annoying;

- Sometimes there are interesting explanations but those are typically "lost"; yes, they are still somewhere in the PR system that was used at the time, in some pull request, tied to a commit hash that is no longer there, because the feature branch was rebased before merge; seriously, once the PR is merged everything that was commented and discussed is lost in practical terms;

So, yeah, I am tempted to try this approach with leaving comments in the code for the author of the branch. I believe it would also make the code review process more efficient.

In short: author of Moq adds the dependency SponsorLink, which is an obfuscated closed source library that collects and uploads data from the developer's machine when the developer builds a project that includes a dependency on Moq. The collected data happens to be the hash of the globally configured git email address of the user at this point in time.

I simply cannot understand why someone, especially the author, would think this is a good idea. How can you not predict this will create a backlash and push users away?

What do you mean? What does this have to do with Windows?

I prefer having a powerful development machine and install and use development environments natively. The only times I am prepared to use a (local or remote) VM is when the development environment cannot be installed on the OS of my development machine, or when I absolutely do not want to install those tools natively (because they might impact my main OS).

I am often involved with multiple projects at the same time, but if those projects are set up well (and the toolset is decent), that does not cause any issues. In practice that means that developers always have to take into account that the project itself includes references to the specific versions of the tools that the project needs. And that those tools are -as-much-as-possible- installed in the context of those projects instead of in the context of the whole machine.

A concrete example in node world is to use "nvm" and to always install tools locally in the context of a project instead of globally. In dotnet world, use global.json to specify the version of the tools you want to work with, install dotnet tools locally in the context of a project instead of globally.

I have worked on projects where this is a problem. For example, projects that depend on hardcoded paths. Or projects that depend on hardcoded connection strings for a database. Or projects that do not use something like nvm to specify the version of node/npm they are compatible with.

Each of those things is an issue with the setup of the project and is something that you will bump against when you try to setup a CI/CD pipeline for the project. Although, I agree that it can be useful to use docker containers with a correct version of the tools to create builds in a build pipeline.

The reason that I prefer to develop natively is that it is faster, snappier and more enjoyable. I also believe that it is easier to diagnose issues and investigate performance. Aside from that, renting a virtual machine with the same performance as my development machine, would be a lot more expensive, and I would still have to deal with the lag. I am aware of recent changes that allow you to for example run a JetBrains IDE locally (similar to what VSCode already had for a long time?) that is connected with a remote headless version of the IDE. I do not have any experience with that kind of setup yet, but I assume that would remove most of the lag.

We use a setup where we have multiple repos with Terraform configuration and thus multiple Terraform states. We then use Terraform remote state to link everything together. I am talking about 10-20 repos and states. Orthogonal to that, we use multiple workspaces to describe the infra in different environments.

The problems I have personally experienced with this approach are:

- if you update one of the root Terraform states, you need to execute a Terraform apply for every repo that depends on that Terraform state; developers do not do that because either they forget or they do know but are too lazy and subsequently are surprised that things are broken

- if you use workspaces for maintaining the infra in different environments, and certain components are only needed in specific environments, then the Terraform code becomes pretty ugly (using count which makes a single thing suddenly a list of things, which you then have to account for in the outputs which becomes very verbose)

Is Terragrunt something that would help us? I do not know Terragrunt, and a quick look at the website did not make that clear for me.

Personally, I would never or rarely use the approach where some code is created and then thrown away. I think it is always better to first think and then do.

With software development, I make the distinction between a functional analysis and a technical analysis. Functional is clarifying the actual business requirements. Technical is clarifying how to implement the new functionality into the system.

During the technical analysis, you are supposed to check and update existing class diagrams, existing api specifications, and so on. Depending on the experience of the team you need to describe this in more or less detail.

The technical analysis must be done by someone who has knowledge of the project. That someone should be aware of the quality of the data in the database, or (in case it is relevant) should explore this while doing the technical analysis. It would also be normal to check the source code while doing a technical analysis to see how things are currently working/built and where the new functionality can fit in.

The reason for investing time in a technical analysis, is to start the implementation with much higher confidence and get a decent implementation from the first attempt.

You must find a balance between the time you spend on technical analysis (without writing any code) and the time you spend on the implementation itself. Spending more time on the technical analysis should save more time on the implementation, but I am aware (and convinced) that some problems will only be found by creating the actual implementation. However, I am also convinced that these problems rarely require a fundamental change in the implementation that a rewrite is needed.

In short, when thinking before implementing, the quality of the first implementation is high enough.

Also, what is not clear to me from the article. The author mentions to have 1-2 highly skilled engineers create a first implementation. And the author likes to be one of those engineers. These engineers create a prototype and then throw it away. The engineer who created the prototype now has an idea how the code must be implemented. How is that information communicated to the (lesser skilled?) engineer who must then implement the new feature?

Right. Why did I not see that? Thanks!

> I highlight this because it's not an unsolvable problem for emacs. It requires making a recommended default configuration that will be more correct for the 95% use case and advocating that configuration on the install channels for the tool.

For people interested in this, I know about Doom Emacs [1] and Spacemacs [2].

[1] https://github.com/doomemacs/doomemacs [2] https://github.com/syl20bnr/spacemacs

I am a long-time Emacs user and used to maintain my own config, but I switched to Doom Emacs [1] a year ago. Doom Emacs is like a pre-packaged/pre-configured emacs distro. You still need to configure the features that you want to use, but it's a lot easier (and faster) than having to do everything from scratch, and definitely if you already have some emacs background anyway. For me, it makes the newer, more advanced, features more accessible. Since switching, I started to use Emacs more again.

[1] https://github.com/doomemacs/doomemacs

Thank you for the statistics, they are interesting. Would also be interesting to know the evolution of those statistics over the last 5 years.

Either way, seems that an IPv4 address is still needed for websites that target a worldwide audience.

I guess this is currently then the biggest issue with IPv6 adoption: ISPs are not yet ready for it.

I'm on an iPhone 7 Plus since a year. It's an old model that I bought secondhand. It was partly experiment. I was using an Android phone: Motorola G5 (also old). I love that G5, but I have the variant with only 16GB internal memory, which is simply not enough nowadays. For me the G5 is still fast enough, but every time there are app updates, I need to free space so the update can install.

My wife was already using a second hand iPhone and convinced me to try it too. I got that iPhone 7 Plus for cheap, it is in really good condition and it has 256GB internal memory. I was aware it would be stuck on iOS 15, but to my surprise, Apple still sends out security updates for iOS 15. I just checked: my phone is on 15.7.7 and I noticed 15.7.8 came out just a couple of days ago. See [1].

I know that Apple is a closed eco-system and all, but for my phone I don't care that much. My phone just has to work. I still use Google products (maps, mail, calendar, keep, chat), but those run just fine on iOS. The other apps I use, are also working just fine (no performance issues).

To me, it's amazing that a phone from 2016 is still receiving security updates. That is simply non-existent in Android world. As someone who does not have the urge to always have the latest and hottest, that is very nice to see.

[1]: https://support.apple.com/en-us/HT212788

Would it be realistic today to make a commercial website only available on an IPv6 address? Or would the website lose too much traffic because of that?

This is similar to an idea I once had about spreadsheets. In my mind it was more focused on being able to handle bigger amounts of data in a more efficient way: a "block" would be a data source and could for example be linked to a database or something else instead of data in spreadsheet cells.

In any case, I think this looks really good.

What I personally would find handy, is if there would be a way to show that one block depends on data from another block. I think it will be common that several blocks will be pure input and other blocks will be pure output. It should be doable to show direct dependencies for a block and the transitive dependencies for a block.

A separate input box for editing cells might also be useful.

I like that it runs in a browser, but I would appreciate if there is a way to run the software locally and store the data locally. And like I said, I would like to see a way to define blocks that connect to a data source, such as a database running locally on my machine.

MyGet (package repository for public and private NuGet, npm, ... packages) has been down for over 24 hours now. While this literally blocks development teams relying on the service, Assembla (that acquired MyGet in 2018) excels at not communicating about the incident. It almost feels as if they want their customers to migrate away from MyGet.

It just boggles my mind how this is even possible. If you run a SaaS business, you should be prepared for scenarios when the service is not available and get it back online as soon as possible. Over 24 hours is just ridiculous.

I started programming about 35 years ago and professionally about 20 years ago.

Some of my thoughts:

- Having the theoretical background is most definitely worth it. I often notice a lack of very basic knowledge on data structures in people who do not have that background.

- Having come into contact with multiple programming paradigms (imperative, object-oriented, declarative, logic, ...) gives you access to more techniques to solve problems and to more ways to think about problems. I believe this is useful even if you only "tasted" these other techniques.

- I notice that people with a theoretical background are often more fluent in learning new techniques and concepts, and in applying techniques and concepts that they know from one language in another language. Understanding concepts and techniques and being able to apply them in other languages is important.

- I believe the field of programming is very big and one person cannot have deep knowledge on every domain in that field. So you have to make choices. In that context I really believe in focusing on broad knowledge in a certain domain and very deep knowledge on a subset of that domain. For example, I personally have broad knowledge on backend development, and deep knowledge on C# and ASP.Net Core.

I really do think that deep knowledge is useful. Developers should try to obtain deep knowledge of their main programming language. Deep knowledge means that you know how to write something in a clean and compact way, that you are familiar with the language's idioms, that you are aware of all mechanisms that the language offers you to write code in a clean and compact way. The same goes for deep knowledge of libraries. Deep knowledge is something that you obtain through experience and by keeping yourself updated on the evolution of the language or library.

The reason I mention "deep knowledge" explicitly is because I have the impression that deep knowledge is not valued that much anymore. Developers jump to the new hot library before they get a full (or even mediocre) understanding of the previous hot library, or they simply do not take the time to learn the language or libraries that they work with. This can then be seen in the code: bad custom code for things that are built-in in the library, using the library in a non-conventional way, ...

Just want to add that you can directly manipulate LINQ expressions. It might be more complex, but you can basically transform an IQueryable into another one. And the result can be used everywhere you can use LINQ.

You can also take advantage of ExpressionVisitor to manipulate expressions.

If you’re in C#, it seems more natural to work with LINQ expressions.

Debian at home and at work.

Been using Debian since Potato. Stable on servers. Testing or unstable on laptops and desktops: quite often a testing base with selected packages from unstable.

Debian just works, and is popular enough that it often has packages for third-party software. And it supports a lot of different architectures, I used it on i386, amd64, powerpc and armhf.

If you want 1 signing key per JWT, you would need to generate a new key pair for each JWT; wouldn’t that be too expensive? Or was the generation included in your tests?

You would not last long in my team. When you “forget” the standard, you would have to rewrite your code. In the end you would perform a lot worse than other team members.

Anyone should be able to follow coding standards, you do not have to be smart for that. You just have to be able to put aside your ego and follow what the team is doing. I am a lot more forgiving to people making mistakes than to people forgetting the coding style.

And anyhow, I enforce the code style by making sure the code simply does not build if you do not follow it.