Follow

Theme of the night: helping out other projects wherever I can. That's 21 pull requests for today πŸŽ‰

I'll probably keep going for another hour or two. Got a project waiting for a review? Don't hesitate and say hello 😊

Β· Web Β· 3 Β· 8 Β· 33

@fribbledom
Wow, that's really cool. It looks like these PRs are mostly about fixing broken windows rather than adding features. I haven't contributed to an open source project yet, but i want to. My trouble is that I rarely spend long enough time on a personal project to be able to contribute to its surrounding technology, and i have little drive to contribute to something i have no stake in.

Do you use the projects you just contributed to, or was the choice arbitrary?

@philipwhite

Yeah, mostly dead simple fixes or corrected typos.

I don't have a stake in any of those projects: some I use, some I just find intriguing enough to check out the code. I guess I just enjoy seeing progress and things moving forward. That feeling is rewarding enough for me.

@fribbledom
Actually, it makes sense. I think I've always felt some obligation to fix an issue or add a feature if I contribute to anything, but fixing small code warts would be a much simpler way to get started.

@fribbledom while you're feeling generous, I'll ask you about my one experience writing in #golang.
I write PHP and Javascript for a living. My first golang script felt more like Javascript (in that everything went into a single file) than it felt like PHP (where everything is nicely structured into class files). Is this normal for golang, or can I chop stuff up?
Repo here: github.com/screenbeard/go-impo - I'm sure there's lots of mistakes you could help me fix, but I'm mostly interested in structure.

@fribbledom I feel like the "Frontmatter" struct (at the bottom of main.go) should be separated into its own maintainable file/structure. Am I missing the point? In JS I often have stuff like

function Foo {
...
}
Foo.prototype.bar = function {
...
}

And #golang feels like that and it feels dirty, but that might just be my limited experience. I much prefer splitting everything out into class files and using PHP's autoloading to just use them when I need them. Do I need to think differently?

@screenbeard

Yeah, in that case I'd just move FrontMatter and its data structures into a separate file, say "frontmatter.go". You don't need to change any imports, it'll still be accessible by everything else in the same package (read: directory).

@fribbledom OK, so just having it in the same directory is enough? Can I use subdirs?

@screenbeard

A sub-dir is a separate package. You can import it, but you can't have circular dependencies, and you can only access public members of that package.

@fribbledom Cheers. That's all good to know. So the idea I guess would be to keep the packages small and self contained and each doing one thing and maybe even separate them out into full packages individually maintained?

@screenbeard

Absolutely! ... and once you grasp how it all ties together with Go's interfaces, you'll really start appreciating the beauty of it.

@fribbledom That seems like some extra overhead upfront if you're making something complex. Would require some thought and care to group stuff into reusable and not reusable, but I can see how it could be a good way to do it.

@screenbeard

Just a heads up: sent a pull request your way over on GitHub πŸ˜‰

@screenbeard

You can use '-tabs=false' with gofmt, but let's just say it's not the recommend way πŸ˜‰

@screenbeard

You usually divide your code by functionality / types into various files within a directory.

That entire directory forms a package, which then can get included as a whole by other packages ("import ...")

It's not uncommon that a single library or app consists of a bunch of packages, so you can divide it up further.

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!