Going back to basics and having zero external dependencies is quite enjoyable. Understanding how Hugo templates, themes, and content all work together was more complicated than I originally expected, but they have build a good system. Hopefully this helps anyone looking to get started.
If you are hacking on this today, you can use this starter repo to get a LaTeX project setup that builds and publishes your document with GitHub Actions: https://github.com/makenew/latex-project
My favorite tag is UPSTREAM to annotate workarounds forced by 3rd party libs or otherwise. Normally I include the link to the associated GitHub issue or SO post.
Tends to be the most useful in-code comment because if someone comes along and "helps" to refactor the "weird" code, they could accidentally undo the workaround and get stuck in the same loop the original author was in.
Last week I ordered a screen protector for my phone. I got two boxes in the mail. I thought I ordered twice by mistake but they had the same order number on the packing slip.
My immediate thought was that some order processing step somewhere is not idempotent.
Oof, I really like Auth0 and was thinking of adopting them soon. Now it just seems like a huge risk. Why would I willfully walk into what will obviously be a migration nightmare and unknown pricing change for one of the central and critical pieces of my application (which should be boring to maintain)?
Best to Auth0! I really hope you can maintain your company culture and excellence, but I can't risk my business on that now.
Production ready skeleton projects for bootstrapping new projects. I've used this approach professionally for over 7 years, but never marketed much past my current team.
Included: JS and Python package /microservice / serverless projects; Serverless Benthos; LaTeX paper; zsh and neovim config.
1. Most project generators don't provide a simple way to keep boilerplate updated. These projects leverage git merge and git diff which is designed for the task. So keeping all the generated projects updated as tools evolve is actually possible.
2. Fork friendly: you can fork and customize these repos to create your own personalized skeleton project, and still merge updates from the original.
3. These projects give you a working CI deployment.
4. The projects themselves are REAL working examples which are deployed / published.
5. Isolated boilerplate so any issues with tooling can be verified, tested, and upgraded independently.
I have a modular family of git repos with a 'dotfiles' one that pulls in the dependencies via bower and handles various bootstrapping and install steps. I also have one for my system config which works similarly. Vim, zsh, and tmux have their own standalone repos with one step install and updating scripts. They are written as normal plugins that load other plugins.
I want to avoid vendor lock-in to something like chef for this. The idea is that everything is either defined in a tool-agnostic config file, and bootstrapping / installing / updating the dependencies is handled by simple shell scripts. Down the road I can always swap out the tooling (bower, config_curator, archutil) without updating code in my repos since state is defined as data.
I don't like syslinks or putting ~/ under git as I don't want my working tree to affect my dotfiles until I run an "install" command.
I wasn't aware of that. I know making it easy to host Supermarket privately is a goal, and already not too difficult, but this seems like an awkward solution for smaller organizations. So far I haven't seen any discussions about adding private repos: I would appreciate if you could direct me there. This is one such thread I've found: https://github.com/opscode/supermarket/issues/217
I would love to see some kind of namespacing: something that would come with organization-specific cookbooks. Really, when I said "don't belong on the main community site" I really mean "don't belong in the current global namespace."
We need something like this for Chef cookbooks. Managed private and public API endpoints for organizations to host cookbooks that don't belong on the main community site,
Even after reading these comments and the new docs it is unclear to me the correct way to use an apex domain on a Project Pages site using CNAME on the root (with CloudFlare) to avoid this issue.
I use a subdomain of that main domain as the User Pages site.
How should DNS be setup and how should the CNAME files on GitHub read?
As an example, the domain on the left should load the site normally hosted from the location on the right:
I am a physics grad student and the paper I just submitted involved a lot of code (mostly fitting in Python plus plenty of LaTeX). I'm really trying to beat the stereotype here and write documented, maintainable, version controlled code. I see plenty of the bad code happening all around me. Research is supposed to be reproducible and the way the code that goes into the analysis is typically handled often runs opposite that goal.
Once I put the paper on the arXiv I open sourced everything and made a portal with links to all the repos. The only thing missing is the repo for the source of the submitted paper which I'll add once it makes it through APS review.
Here is my work if you're interested or have any feedback: