This s6 config is awesome value and I don’t think you’ll be disappointed, especially running in 18350 mode.
Found this beamshot on the other site but I can also say from personal experience that theres a nicely defined hotspot for a tube light.
This s6 config is awesome value and I don’t think you’ll be disappointed, especially running in 18350 mode.
Found this beamshot on the other site but I can also say from personal experience that theres a nicely defined hotspot for a tube light.
Time zones are an endless source of frustration, this one doesn’t sound too bad though:
Going forward, all timestamps in the API are switching from timestamps without time zone (
2023-09-27T12:29:59.113132
) toISO8601
timestamps (e.g.2023-10-29T15:10:51.557399+01:00
orZ
suffix). In order to be compatible with both 0.18 and 0.19, parse the timestamp asISO8601
and add aZ
suffix if it fails (for older versions).
Real RGB? Does this mean we can now control the color?
That’s right, check out https://lemmy.world/post/3287635 for some pics.
I was confused about the engraving but I like your idea to ask for “no engraving” as the option. Only the first 30 get a custom one so maybe everyone else will have the logo engraving.
A more focused throw channel with the same color temperature as the flood channel would be great.
Sft-70 is 6 volt right? Otherwise this would seem like the perfect spot for an sft-40 3000k.
I can see you like Anduril! Except for the wurkkos ts12.
How do you like the brass ts10? Seems like a great value and is on my list to potentially get.
Sticking with the 14500-theme, my first hank light might be a D2 if I can settle on an emitter combo.
Cool project and post! There’s also !flashlight@lemmy.world if you’d like to cross post.
gets hot enough to burn you if you leave it on for too long
That Fenix looks like a reliable light and is designed with temperature regulation but the limit might be pretty high and of course it is being used in an enclosure.
candle mode
This might be the problem, candle mode has no thermal regulation if I remember correctly.
Glad you weren’t hurt and hopefully the cell can be rewrapped.
Feels odd for admins be able to prevent users from seeing content
My understanding is those admins aren't just allowing users to view it but also allowing copies of the federated data to be stored on the server those admins are responsible for, so for certain types of content it seems really important to be implemented in this way.
Imagine you need (or just want) to carry several flashlights for different use-cases: seeing far away, seeing nearby, lighting up your campsite with a warm glow, or emitting a specific color.
Multi-channel lights aim to consolidate multiple use-cases into a single flashlight. And although 2-channel lights are available, this might be the first 3-channel available from a flashlight maker who allows customers to customize their LED choices from the factory.
Focusing on code coverage (which doesn't distinguish between more and less important parts of the code) seems like the opposite of your very good (IMO) recommendation in another comment to focus on specific high-value use-cases.
From my experience it’s far easier to sell the need for specific tests if they are framed as “we need assurances that this component does not fail under conceivable usecases” and specially as “we were screwed by this bug and we need to be absolutely sure we don’t experience it ever again.”
Code coverage is an OK metric and I agree with tracking it, but I wouldn’t recommend making it a target. It might force developers to write tests, but it probably won’t convince them. And as a developer I hate feeling “forced” and prefer if at all possible to use consensus to decide on team practices.
We can’t test yet, we’re going to make changes soon
This could be a good opportunity to introduce the concept of test-driven development (TDD) without the necessity to “write tests first”. But I think it can help illustrate why having tests is better when you are expecting to make changes because of the safety they provide.
“When we make those changes, wouldn’t it be great to have more confidence that the business logic didn’t break when adding a new technical capability?”
You shouldn’t have to refactor to test something
This seems like a reasonable statement and I sort of agree, in the sense that for existing production code, making a code change which only adds new tests yet also requires refactoring of existing functionality might feel a bit risky. As other commenters mentioned, starting with writing tests for new features or fixes might help prevent folks feeling like they are refactoring to test. Instead they’re refactoring and developing for the feature and the tests feel like they contribute to that feature as well.
Thanks for posting this. Additionally, I think highlighting some great posts in the sidebar like @containerfan@lemmy.world ’s Anduril diagrms https://lemmy.world/post/1038159 would be great since it shows what’s unique about this small community (on Lemmy).