Kind replies

 Reply

I've got a meta page for all my feeds but https://www.jvt.me/kind/articles/feed.xml is probably the main one that folks are interested in!

 Reply

I thoroughly enjoyed working with Andy to design a project logo for an Open Source project I've been building.

Wanting to work with a real human and get their experience and breadth of ideas, Andy was a great choice, having been recommended by a connection on social media, and helped me unpick what I wanted out of the logo, providing several avenues for design choices before honing in on the final design, which I was super happy with.

Andy was great to work with, provides a wealth of experience and knowledge and was great to work with. I really enjoyed the usage of both synchronous discussions (over video call) and using Miro for asynchronously describing the design decisions in each iteration of the design, allowing me to hear his thoughts (rather than just read them over email) and respond to them in kind.

I've recently started a second project with Andy, and can definitely foresee using his services again!

 Reply

Being fortunate and not getting sick during the pandemic (yay social distancing and masking!) and I got sick over the holiday period and dang it sucks to be ill, I can't believe it used to be way more often in the past ๐Ÿ˜ท๐Ÿค’

 Reply

I'd recommend Stoplight Elements for OpenAPI visualisation over the Swagger Editor (for more reasons than it still using the legacy name Swagger)

The hosted demo doesn't allow providing it a URL, but I've got a version spun up that renders a spec you upload - the usual caveats about not trusting online tools apply!

 Reply

Thanks very much, that's very nice to hear, especially from a complete stranger ๐Ÿ˜

I'll be sharing these updates with my team on Monday, and this deffo fills me with more confidence, thank you!

 Reply

I'd personally be interested ๐Ÿ‘€

 Reply

Not personally used it, but Vale is well recommended with technical writers I know (but may require some configuring), ie https://lornajane.net/posts/2024/reviewdog-filter-settings-with-github-actions from @lornajane may help with using https://github.com/errata-ai/vale-action

 Reply

Alternatively:

jq "." posts.json > better.json

(to remove "useless use of cat")

 Reply

Should there be a www. prefix to the URL, here? ๐Ÿ‘€

 Reply

On my side I stopped using Meetup as heavily when they removed the free API, and post-lockdown, at least nearer to me, there aren't nearly as many in-person meetups.

In the #IndieWeb community, there's the Meetable project, seen at https://events.indieweb.org/ and is powered by IndieWeb tech (not ActivityPub) if you fancied self hosting, but then you miss out on network effect and discoverability of events you're not necessarily organising yourself ๐Ÿค”

 Reply

๐Ÿ‘‹๐Ÿฝ Co-maintainer of oapi-codegen here, this is something that can be fixed by migrating the type on the spec side to a named Schema, but will see if we've got a planned feature to autogenerate a type name here instead of an anonymous struct ๐Ÿคž๐Ÿฝ

 Reply

Parul's talk was incredible - her humour and reflection on her experiences of life as a neurodiverse person, through the lense of "what if neurotypicals were the weird ones" was really quite powerful.

I spent the talk very eagerly nodding along and laughing - a little distractedly - at her incredibly relatable take on the role reversal, and bangers like "Norman received feedback [that his colleagues felt weird about him because] he couldn't fidget".

I'm biased as someone who is neurodiverse myself, so related much more heavily to the talk, but feel that non-neurodiverse people in the audience could also understand the parallels.

I was very strongly reminded - in a great way - of Rachel Morgan-Trimmer's talk from OggCamp 2019 which was also a really powerful insight into life as a neurodiverse person, and I really enjoyed Parul's empathy-driven talk.

I especially loved the ending call to action, asking us all to consider what steps we could take to understand others in our life better.

My only complaint was that I wish the talk was recorded!

(I unfortunately missed the first few minutes)

 Reply

Nice, see you there ๐Ÿ‘€

 Reply

Nice! This is one I've ended up needing to do a few times too

 Reply

Ohh gotcha I see what you mean - so it's actually that the map isn't initialised (still one of the annoying things Go does, you have to make(map) to initialise it), the key being unused just stops us compiling.

I do agree it'd be useful to have a way to catch uninitialised maps earlier!

 Reply

Yeah not sure where that came from but as you say, you can pin to a tag/commit, and Go's module proxy stops you from having someone re-push the value of a tag, once it's had someone download a dependency.

You also only pin, as there's no way to do a range, so IMO that makes it nicer and more explicit than other languages / toolchains with respect to pinning

 Reply

Yeah I'm very much looking forward to // tool landing as that'll push more folks to using a tools.go style approach.

I'm seeing some folks who'll use a tools.go in a separate Go module so then it doesn't impact the top-level dependency tree, on top of Go' s inbuilt module graph pruning

Also as much as I recommend tools.go, there's still some things it can be awkward with ie golangci-lint tracked as a source dependency can lead to issues (dependency version clashes, Go version incompatibility), as well as it not being the recommended use case

 Reply

Yup! I wrote about this in a bit more detail a few months back

 Reply

Hand writing the spec, then validating (ie via http://gitlab.com/jamietanna/httptest-openapi) is a valid option - keeps it in sync very well from quite a few big Go apps I know using it

Or you could wrap your implementation in https://github.com/oapi-codegen/oapi-codegen/ from a hand rolled spec - we support net/http - and that then starts towards the process of being closer to the spec

Either way, you still need to validate the spec and implementation are in sync, and IMO, hand-writing the spec is the only "right" solution that makes sure you're intentionally making changes to the API, whereas generating spec from code could lead to just documenting what's in place and ie accidental breaking changes being missed

 Reply

I used to do this - especially with t-shirts at stake - but since last year I'm not as bothered ๐Ÿคท๐Ÿฝโ€โ™‚๏ธ

Now I try and raise PRs when I can, otherwise I'll forget about them ๐Ÿ™ƒ

 Reply

Would love to hear about this ๐Ÿ’œ as someone who does something somewhat similar, somewhat passively (publicly sharing my salary history), I can attest to how important it is to chat about it with your friends and colleagues and work to get better ๐Ÿ™Œ๐Ÿฝ

 Reply

They can be useful, but at least my OSS doesn't need them much. I've got some work bits that do have Musts for convenience either in func main or as you say, in tests

 Reply

I'd say that adding a separate /x/ or /exp/ package can also be a good way of testing out new things - very clearly a separate "experimental" thing, which can be tested independently

Using a fork of the module is also a good suggestion and a way to make sure it's not even in the main repo, but gives you mostly the same codebase to be able to test things

 Reply

Aaron Parecki wrote Meetable - more info - which isn't quite a replacement for the platform and it's social aspects, but is used in a few places including https://events.indieweb.org

 Reply

go-semantic-release has this same default but thankfully it's straightforward to set it so you can use 0.x releases.

Making it the default is IMO a very bad decision, as it teaches people that they should go to 1.x far too early.

My grumbling will result in a blog post sooner than later ๐Ÿ‘€