Seems like an interesting article, but I really distike some of the website choices here. Why is the first sentence, just the title repeated? Why do you have ads for five other articles mixed in with the content? The article is not that long, so that seems like way overkill.
> Why is the first sentence, just the title repeated?
An artefact of using Ghost defaults; I've moved the excerpt from the main article into the social media cards section to improve readability.
> other articles mixed in with the content
By referencing the other articles which are relevant to points made within the post becomes shorter.
> The article is not that long
The post is meant to be short because it's about a simple convention that I've adopted that has helped me. Maybe others will find value in the idea as well.
I see what you’re going for, but I agree the article snippets are a poor design choice. I keep losing context while trying to read the article. The article blocks feel like section breaks, but they’re not.
There are already links in the paragraph text, and those links are highlighted a different color. I can click on them to see the other article if I’m interested.
I’m inclined to agree. At first, I wasn’t sure if those blocks were ads or other articles on your own website; they interrupt the reading experience in an unpleasant way.
Another hopefully helpful piece of feedback: "as per say" is incorrect. The correct spelling is Latin, "per se", meaning "in itself". It also doesn't make sense to preceed it with "as".
I'm reading it on a mobile browser and I strongly agree with apeace, the blocks interrupt the flow. Maybe it would be better if the images weren't in each block, or maybe if the images weren't the same size as the image above the article text. All told each block is more than half the height of my screen and each paragraph is a bit less than half the height so it feels like I'm reading the first paragraph of several distinct articles (like an RSS feed?).
Traditionally, I'd think of setting up my developer machine as spending a day or so to install all the programs I need to work on whatever projects.
Services like GitPod are about serving a development environment remotely.
The blogposts discusses dotfiles as a social thing. e.g. you should be able to fork someone's dotfiles repository as a good starting point for your dotfiles.
The idea in the blogpost is a suggestion which combines this idea of sharing dotfiles, with the idea of being able to quickly spin up a developer environment.
Bypassing the whole set of issues that "having a development environment remotely" introduced (isn't that just "testing" environment at that point by the way?), dotfiles are inherently personal configuration files, otherwise it's just application configuration, so not dotfiles anymore. Nothing wrong with sharing dotfiles, I do that plenty myself, both sharing and using parts from others, but it's on my own accord and system-wide, not project specific.
Project-specific configuration is just that, project-specific configuration, and you would not call it dotfiles anymore.
I found a good explanation on stackoverflow [1] by one of the co-founders. It let's you can spin up a newly provisioned dev environment from any github repository, so you can work from any client (like an iPad).
Also by defining dev environments in code that can be deployed on-the-fly (aka infrastructure-as-code), that allows you to do things like share the code with others, who can "fork" your dev environment with their own customizations. This seems to be what OP's article is about.
Yeah, very confusing title. I was wondering if "dotfiles" had a completely different meaning than the obvious one, but his link to it was exactly what I expected.
I guess what he means is not so much the dotfiles themselves, but the customization and sharing of them, and not for computers, but for containers, and not dotfiles, but Docker configuration. But other than that I'm sure it's basically the same thing.
They're likely referring to "storing your config data in a repo" as "dotfiles" here. It makes sense in that light: where backing up your config data makes life easier for you when you set up a new machine, this makes it easier whenever you'd like to demo new software by creating a mini-VM. This is just expedited sandboxing with web access built in.
The two feel complementary; you'd likely still want your dotfiles included in the images you're spinning up.
Dotfiles are generally the set of preferences applied. Implicit though is also usually the set of tools installed. Generally I'd say the idea is to make one's environment semi-portable, something you can get, wherever you go.
The idea here is to have, rather than a set of configurations you can deploy wherever you go, a factory that produces ready to go computers on demand.
This post makes a lot of sense to me, & is a good exploration of what our environments are, & how they might be expanded & better able to serve, especially as we get better containerized systems. This approach is web based, and with nice integration work like Toolbx[1] I expect this sort of primed, ready-to-go, containerized development strategy being more popular. Having everything ready, but having it all still be "cattle" not "pets" allows for a lot more unchecked & wild experimentation during development.
i think what makes it confusing is he links to an article on his own blog every 1 to 2 sentences. really takes away from whatever this actually is, which is apparently something that allows him to code on an iPad. sigh
I understand the author mentioned doing software development on an iPad, but it wasn't clear that was what you were referring to. Many (including myself) would disagree that it's broken by design. Depends on your use case.
Here I was hoping this was a new standard for configuring installs using like YAML or something. God, Microsoft, Apple, etc could really benefit from having a standard API for installs.
/new is a route on his webserver, which when clicked sends them to a web-based IDE, primed and ready to go with their set of dotfiles & configuration, namely, https://github.com/ghuntley/new
> By taking lessons learned from the infrastructure-as-code movement and upgrading the dotfiles pattern into full blown Docker images then utilising products such as Gitpod to consume, build and execute the Dockerfile then I no longer need to worry about the security of my endpoint when playing with open-source software created by complete internet randoms.
34 comments
[ 0.99 ms ] story [ 81.2 ms ] thread> Why is the first sentence, just the title repeated?
An artefact of using Ghost defaults; I've moved the excerpt from the main article into the social media cards section to improve readability.
> other articles mixed in with the content
By referencing the other articles which are relevant to points made within the post becomes shorter.
> The article is not that long
The post is meant to be short because it's about a simple convention that I've adopted that has helped me. Maybe others will find value in the idea as well.
There are already links in the paragraph text, and those links are highlighted a different color. I can click on them to see the other article if I’m interested.
I don't believe these are ads, but just previews of the linked content.
Also are you adding in tailscale so that you can then reach the container from your iPad as well?
Services like GitPod are about serving a development environment remotely.
The blogposts discusses dotfiles as a social thing. e.g. you should be able to fork someone's dotfiles repository as a good starting point for your dotfiles.
The idea in the blogpost is a suggestion which combines this idea of sharing dotfiles, with the idea of being able to quickly spin up a developer environment.
Project-specific configuration is just that, project-specific configuration, and you would not call it dotfiles anymore.
Also by defining dev environments in code that can be deployed on-the-fly (aka infrastructure-as-code), that allows you to do things like share the code with others, who can "fork" your dev environment with their own customizations. This seems to be what OP's article is about.
[1]: https://stackoverflow.com/a/63595356
I guess what he means is not so much the dotfiles themselves, but the customization and sharing of them, and not for computers, but for containers, and not dotfiles, but Docker configuration. But other than that I'm sure it's basically the same thing.
The two feel complementary; you'd likely still want your dotfiles included in the images you're spinning up.
The idea here is to have, rather than a set of configurations you can deploy wherever you go, a factory that produces ready to go computers on demand.
This post makes a lot of sense to me, & is a good exploration of what our environments are, & how they might be expanded & better able to serve, especially as we get better containerized systems. This approach is web based, and with nice integration work like Toolbx[1] I expect this sort of primed, ready-to-go, containerized development strategy being more popular. Having everything ready, but having it all still be "cattle" not "pets" allows for a lot more unchecked & wild experimentation during development.
[1] https://containertoolbx.org/
Stop developing on broken by design platforms?
/new is a route on his webserver, which when clicked sends them to a web-based IDE, primed and ready to go with their set of dotfiles & configuration, namely, https://github.com/ghuntley/new
Bingo!