Do something like one project per month with one topic among the above per week. Haven't found the right group of folks to experiment on with this yet.
Edit: Send me an email if you'd like and I'll think about hosting this virtually.
Done right I think that may go somewhere.
The biggest hurdle for me has been actually finding a project I'm interested in where I haven't yet gone poking around the source code for some reason or another.
It's a pain to write about because you have to find some contrived error (real or not) in a contrived app. I've got a draft of a post but without the examples filled in.
Would like to read (and share) what you've got.
Now we're having multiples of codebases to comb through.
I'm not sure it needs de nuovo examples, just general advice and techniques from long experience.
I remember finding this talk useful and general good advice: https://www.youtube.com/watch?v=wN4ZuGruiNw but would love to learn more about how others do it.
Would be great to see your impressions as you dig into it and maybe record yourself on youtube. Any way I can be of assistance, let me know.
We both do some pre reading of the topic, and "pair program" through it, changing some bits and running the code to see if the current mental model still holds. The person who drives has to be very verbose explaining what he's doing ("Let's go to this function definition, ok, we see this struct here, let's leave a mark for later and visit that struct"), because otherwise, the one watching is like "wtf, are we looking at now".
We're currently going over emacs' native compiler branch and it's been lots of fun so far. The conversational interaction of Lisps makes those explorations very lively.
I'd be interested in joining, of course :)
FWIW: I started a study group in the late 90s, which continues today.
Our original topic (theme) was Design Patterns. Took three attempts to become self-sustaining. Mostly for an in-group to congeal. We had to experiment with the format, work out the details. Stuff like meeting frequency, best way to do the food, delegating tasks.
After each book, the group gets together to choose the next book. Over the last 20+ years, we tackled most vogue programming languages, Prolog, SICP, concurrency, ML & big data, k8s, methodologies, algos. (One notable omission are the consensus algos.)
So here's my unsolicited advice:
#1 As soon as you can, delegate the discussion leader task, then step back and focus on coordination (hosting). Once you figure out a mostly working format. After showing everyone how it's done, hand it off. Ideally, do round robin with the participants. After a while it becomes clear who's good at discussions.
First reason is coordinator is a full time job itself. Preparing to lead a discussion is a lot of work and a different headspace. Reading the source material, doing background research (reading other reviews of same), distilling 3-5 essential open-ended questions about the chapter, etc.
Second reason is emotional engagement, investment. Everyone has to pull their weight. Just like with a church, there's no commitment without sacrifice. You're hosting a discussion group, not a seminar.
#2 Experiment, have a plan, make decisions democratically, do post mortems after each series. Ask each participant to write what worked, what didn't, what they'd change (aka The Good, The Bad, and The Ugly). Send all write-ups to group pre meeting. Then discuss.
As coordinator, my job was to facilitate, carry out the group's will, keep everything on track. (Well, mostly the job was to show up.) There have now been a handful of coordinators; so apparently our culture and format were successful.
So if I was going to tackle AOSP today with a new crew, I'd draft a plan, invite everyone to also propose plans, present plans to the group, have a list of open questions to be decided, keep a list of new questions raised, keep minutes, send out a recap. I'd probably host every thing on git, to ease collaboration.
My opening position would be to suggest a first "season" 4-6 months long, meet alternate weeks, use a survey to divine which chapters to cover (based on group interest), another survey to divine meeting schedule.
Ok. Enough of my brain dump.
Again, whatever you end up doing, please do a Show HN.
What you're doing is very exciting. Happy hunting.
The maintainer expresses some regret about the parser architecture. I referenced this in several 2016-2017 blog posts:
OSH Parses Shell Scripts Up Front in a Single Pass. Other Shells Don't - http://www.oilshell.org/blog/2016/10/13.html
OSH Can Be Parsed With Two Tokens of Lookahead - http://www.oilshell.org/blog/2016/11/17.html
The Thinner Waist of the Interpreter - http://www.oilshell.org/blog/2017/01/26.html
Word Evaluation - http://www.oilshell.org/blog/2017/03/09.html
This principled architecture ended up paying off in a couple unexpected ways, which I wrote about earlier this year:
Oil Uses Its Parser For History And Completion - http://www.oilshell.org/blog/2020/01/history-and-completion....
Oil's Parser Doesn't Worry About Aliases and Prompts - http://www.oilshell.org/blog/2020/01/alias-and-prompt.html
Summary: in addition to the regrets expressed by the maintainer in the article, bash actually has multiple ad hoc, incorrect parsers for its own language! They are incorrect to the point that a separate project (bash-completion) has code to paper over the errors.
Oil uses the same parser for all use cases. Moreover, its parser isn't littered with orthogonal concerns like the interactive prompt and expanding aliases.
However I still need help finishing the project -- see what I've cut here: http://www.oilshell.org/blog/2020/08/risks.html
And feel free to contact me (address on home page and in profile)
2011 (a bit) https://news.ycombinator.com/item?id=2578071
There have been many other submissions (https://news.ycombinator.com/from?site=aosabook.org), but those seem to be the nontrivial threads about the book itself.
Building Apache from source (including a few key addon modules) and configuring it to work for a small set of tests was step 1 at my organization then. Those successful at this would then get into the source itself.
Isn't that a hallmark of a junior engineer :) ? If you're trying to achieve deeper technical depth (which takes time), it helps to be a part of an organization that rewards said technical depth.
I agree. My previous job wanted to employees to finish work ASAP. There were no incentives for quality. Performance was judged on the basis of how fast one can push things out irrespective of quality.
As a result there was lack of engineering.
Of these, I liked the chapters on Bash, BerkeleyDB, and Graphite better than those on Asterisk, Audacity, CMake, and CI. I had trouble getting through the chapter on Eclipse, although there were some interesting bits.
The chapter on Bash suffered a little, in my personal experience, because about 70% of it was a rehash (with a slightly, but not sufficiently, different perspective) of information present in the Bash man page, which I had previously read in a reading group with some of these same people.
But really, the chapter that's best to study is probably the one you're currently most interested in, even if it's "not as good" as another considered in the abstract. Just remember not to assume that the entire book is of the same quality, whatever your experience.
I wonder how some of these architectures have really helped with maintenance. For instance, I'm familiar with Open MPI and its rather sorry maintenance history with continual breakage and at least partially unnecessary lack of compatibility. Then it still seems the best bet for general purpose MPI...
https://wiki.freecadweb.org/Developer_hub (I especially liked the forum post from the contributor who detailed the geometric constraint solver - very neat)