6
ECE and the .au domain
(programming.dev)
Wordle 1,065 X/6
🟨⬛⬛⬛⬛ ⬛⬛⬛🟩🟩 ⬛🟩🟩🟩🟩 ⬛🟩🟩🟩🟩 ⬛🟩🟩🟩🟩 ⬛🟩🟩🟩🟩
I feel cheated
Open source software literally means that the source code is available to anyone. In GitHub, that just means that your repo is public rather than private. But your method technically doesn’t matter. You could publish to a forum if you wish. That’s still open source!
Free OSS just means that anyone is free to use and modify the source code for any purpose. The details are usually defined in a LICENSE file.
I feel like you’re really asking about the common practices and methods used in FOSS. Right? If so, that’s entirely up to you as the maintainer. As the project matures, you may attract other contributors which will in turn will motivate change to your tools and methods.
Start with what works for you. Model after similar projects if you wish. Adjust as change is needed.
I certainly don’t have an answer for you. Sorry 🙂
I’m super curious about your motives and goals though. Why do you want to do this??
Lol whoops. You’ve got it right. I fixed up my previous comment
The video plays for me as well but no sound. I’m using the PWA on iOS.
I think you’ve had a little mixup! Looks like this community is Visual Studio, which is completely unrelated to Visual Studio Code. We can thank Microsoft for that naming disaster 🫠.
If you’re asking about Visual Studio, then the GitHub proposal link isn’t relevant because it’s for VSCode. And if you’re asking about VSCode, then come ask in [email protected]
This one was brutal!
I got it in 3, which is nice. But it took me like 20 minutes to solve 🫠
Wordle 1,054 3/6
⬛⬛🟩🟩⬛ 🟨⬛🟩🟩⬛ 🟩🟩🟩🟩🟩
lol got it. Definitely not email then
Uh email? It’s not exactly exciting but there are loads of tools available for automating emails. Definitely asynchronous. Does it fit your needs?
Test coverage is useful to measure simply because it’s a metric. You can set standards. You can codify the number into ci/cd. You can observe if the number goes up or down over time. You can argue if these things are valuable but quantifying test coverage just makes it simpler or possible to discuss testing. As people discuss test coverage and building tests becomes normalized, the topic becomes boring. You’ll only get thoughtful discussions on automated testing when somebody establishes a new method, pattern, etc. After that, most tests are very simple. That’s often the point.
Even “testing on autopilot” has high value.
You can build lots of useful front end tests. There are tools for it. But it’s just not possible to test everything because you can’t codify every requirement. E.g. ensure that this ui element is 5 pixels below some other element, except when the window shrinks, and …
I haven’t seen great front end tests. But the ones I’ve seen mostly focus on functionality and flow rather than aiming to cover all possible scenarios. Unit tests are different in this regard.
Integration testing makes sense but I find it hard to do in the time I have.
This is a red flag. Building tests should be a planned part of your work, usually described as acceptance criteria. If you need 4 hours to write a code change, then plan for 8 or whatever so you can build tests. Engineering leaders should encourage this. If they don’t, I would consider that a cultural problem. One that indicates a lack of focus on quality and all of the problems that follow.
Edit: I want to soften my “red flag” comment. That’s a red flag for me. That job isn’t necessary bad. But I would personally not be interested. It’s ok to accept things like, “we don’t write tests and sometimes we deal with issues”. Especially if it’s a good job otherwise.
Here’s my random collection of thoughts on the subject.
I have no idea how common it is in general. Seems like some devs build tests while others don’t. This varies plenty on a team level as well as organization wide. I’ve observed this at small to very large companies, though not FAANG where I generally hope and expect that tests are a stronger standard.
I will say that test are consistently and heavily used in every large, open source project that I’ve reviewed. At some point, I think quality test cases become a requirement.
Here’s the big thing. Building automated tests is almost always a wise investment, regardless of the size of the org. Manual testing is dramatically more expensive and less effective than running unit and integration tests. I’ve never written unit tests and not found issues.
More importantly, writing unit tests forces you to write code that can be tested. This is important. IMO, code that can be tested is 1) structured differently and 2) almost always better.
Unit tests protect you from your own mistakes. Frequently. Integration tests protect you from other people. E.g when your code depends on an api and that api unexpectedly introduces a breaking change.
Everybody likes having quality tests. Nobody likes writing tests.
Quality tests are basically a strict requirement for fully automating ci/cd to production. Sure, you can skip tests and automate prior deploys, but I certainly don’t recommend it. I would expect people to be fired for doing this.
Chasing 100% test coverage is a fools game. Think about your code, what matters, and what doesn’t. Test the parts that add value and skip the rest. This is highly related to how writing unit tests change your code.
Building front end tests is inherently hard. It’s practically impossible to fully test front end code. Not even close.
Personally, I like the idea of skipping tests when you’re building a POC. Before the POC is done, you may not know if your solution is viable or what needs to be tested. The POC helps you understand. Builds tests for MVP and further iterations.
Quality ci/cd tests are complimented by quality observability, which is a large and independent topic.
/ ramblings of a tired mind
Well that’s cool. Sounds like the workspace extensions are inspired by the tools.go pattern. Something that I recommend any go developer dig into!
3
Here's an upcoming feature for those wanting to use multiple profiles in VSCode but don't enjoying micro managing settings across many different profiles. And good news: This feature is currently being developed!
The feature request is Extend from the Default Profile. The idea is to allow users to organize settings into various layers. Global settings in the default profile. Maybe python specific settings in a python profile. And then golang specific settings in a golang profile. Or however else you want to organize things! This will be a huge help when working with many different workspaces and languages which all need little adjustments.
This idea actually dates back all the way to November, 2016! While it has nearly 600 votes, nobody implemented the feature. Thankfully, the new feature (again, issue 156144 was requested about a year ago and was actually a part of the Iteration Plan for June 2023. Unfortunately, it wasn't completed in time (that's ok! Thanks devs!) and was pushed to the July 2023 iteration. Hopefully, we'll have this feature released soon.
If you're as excited as I am for this one, then vote for the feature with a thumbs up.
Yes, it's already in development but votes can make this feature a priority. You can also vote for specific implementation details too!
15
Hidden Gems: VSNotes by Patrick Lee
(marketplace.visualstudio.com)
This is the first of a (hopefully) recurring series where we showcase extensions that are likely unknown to most users. Starting with patricklee.vsnotes!
Marketplace Description
VSNotes is a simple tool that takes care of the creation and management of plain text notes and harnesses the power of VS Code via the Command Palette.
Why I like it
VSNotes seems to be built for frequent note taking. E.g. Taking daily meeting notes and keeping them organized. There are quite a few alternative extensions like dendron.dendron that do this quite well but are much more complicated. I like VSNotes for its simplicity. It's easy to use.
More importantly, I don't want to create a large number of notes. I just want to manage a few organized files and have them accessible at all times. Here's a screenshot from my work laptop.
No date stamps. No tags. No subdirectories. Nice and simple. Having these notes embedded in VS Code gives me the expected benefits like markdown syntax and preview. But my favorite part is the Activity Bar icon (far right in my screenshot). These notes aren't stored in my active workspace. They can be but I choose to store these notes in ~/notes instead. This means that the files within that directory are globally available regardless of which workspace is active. If you work with many different repositories and workspaces, this is fantastic!
A few use cases
- Basic notes that are always open... duh. So you don't have to send yourself messages in Slack
- Commands.md: Some bash magic. Some kubectl favorites. Some fancy git commands. All copy/paste-able into the embedded terminal
- Diagram.d2: I manually set the file extension. Now I can preview terrastruct.d2 diagrams conveniently!
My Configuration
{
"vsnotes.defaultNotePath": "~/notes",
"vsnotes.defaultNoteTitle": "{title}.{ext}",
"vsnotes.noteTitleConvertSpaces": "-",
}
view more: next ›