ReactiveCocoa.github.io
ReactiveCocoa.github.io copied to clipboard
ReactiveCocoa
RAC Blog
Any feels on a collaborative blog on reactivecocoa.io?
In separate discussions with @indragiek and @Coneko, we each feel we should write more about RAC because we have insights and experiences to share. With a couple of exceptions, most of us aren't prolific writers, but maybe collectively we can have a good thing. There have been a bunch of people writing about RAC lately, how does everyone feel about those? Should RAC have an official speaker box?
Obviously such a blog can live anywhere, I just wanted to see what the feels are about having it on reactivecocoa.io.
Related to ReactiveCocoa/ReactiveCocoa#1162
/cc @ReactiveCocoa/reactivecocoa @jonsterling
I would definitely like to see blog posts coming from the "official" source. If anything it should serve to counteract all the, unfortunately, misleading articles out there at the moment.
@dannygreg The team as a whole won't have the time to proofread and vet every article, so it should probably be a "the views expressed here are solely those of the author" kind of thing, not official, but closer to the source. (I guess that's what you meant by "official" too)
Still I think writing the articles through PRs would be helpful, I know I'm not very clear when I write and could use inputs on my drafts.
Yeah, I think this would be very useful. I stress, though, that I think it's very important to have peer review before publishing, just because of the very high risk of saying something that seems right at the moment, but ends up being wrong or confusing to the audience. We all have different strengths, and would likely benefit from a PR-based review process with (unanimous?) sign-off.
It seems like nearly every blog post about RAC I have read has been misleading in one sense or another, or has been full of things like “I don’t quite understand it well enough yet to see the benefit of using composition, so I recommend using it as a replacement for KVO” (<--- If you feel that way, please don’t write a tutorial yet!). We would seem to have an opportunity to set straight the record a bit, and would benefit from collaborating on a “common language” for informally describing FRP/MVVM-style architectures & techniques.
I agree with @jonsterling, there should be a strict peer review process (PRs as suggested by @Coneko would be the most convenient) to avoid the issues that are present in other articles. Even if everyone doesn't have a chance to review it, at least having 2 or 3 people sign off on it would be enough to ensure that it's of reasonably good quality.
Great, everyone feels strongly about this! Let's not get ahead of ourselves on the process or quality. There's no shortage of opinions here, I can't imagine a scenario where something shoddy gets published. Worst case is some things just don't get published here, but that doesn't stop anyone from taking their writing that received some reviewing and publishing elsewhere. This blog idea is a means to an end: that more of our knowledge and insights are shared, one domain or another.
I don't know how one does this kind of thing, but I'd guess it starts out with figuring out the scope. Who are our readers, who are not our readers. Which topics do we want to cover vs not cover? In the case of disagreement, GitHubbers obviously have the final say.
:+1: on PRs.
GitHubbers obviously have the final say.
I don't agree with this. @Coneko, for example, has a better perspective on things than myself.
A consensus will be obvious in most cases. If it isn't, just don't publish.
I meant collective final say, but yeah I wasn't getting ahead if myself at all :trollface:.
Either way, a natural order already exists.
Do you guys think it would be a good idea to start off with an "intro RAC" series that goes over the basics, introduces some FRP concepts in contrast to imperative solutions, etc.? Ideally they would be focused on things that are common in Objective-C programming, but could be implemented in a better way using RAC. Here are some post ideas for the basic concepts:
- Intro to FRP
- The difference between traditional imperative Objective-C and declarative code using RAC
- Explain to the world what a monad is. @robrix explaining this while on sleepy meds would be a huge bonus.
- KVO, bindings, notifications (and how RAC creates a uniform abstraction around those things)
- Chaining asynchronous operations vs. NSOperation, schedulers
- Using higher order functions vs. mutable collections and loops (this one is more relevant to FP than FRP but I think it would still be useful)
- Commands vs. target/action
I realize this sounds a lot like the simplistic examples that we're trying to avoid here, but I believe these things could still be good topics for blog posts if we're really careful not to oversimplify the subject matter and provide some really good examples with plenty of explanation and justification for why this approach is better.
After the introductory stuff is out of the way, we could move to some higher level things:
- Incremental refactoring of existing OOP design patterns to FRP (subjects, delegates -> signals using
-rac_signalForSelector:, lifting selectors, etc.) - MVVM using RAC vs. Cocoa MVC
- Using composition to implement more complex systems that would be difficult otherwise
@kastiglione and I also discussed the possibility of "RAC My Ride" posts where the goal would be to have reader submissions sent in and we would transform them into idiomatic RAC implementations with plenty of explanation on the benefits of the RAC approach.
I'm in love with this idea.
We're currently using a tool called Middleman to create the static pages from the site branch. Middleman supports static blogging, too. I'll explore how to set that up, as well as CSS styling for the blog portion of the site.
I've opened a pull request that creates a blog in our middleman site. Let me know if there are any questions.
@dannygreg I've had the RAC My Ride idea in the back of my head for a while, but only just recently started to try to bring it to reality. Would it fit here, something like a tagged series on the RAC Blog?
@AshFurrow Awesome, thanks!
Should there be a meta first post introducing the blog? Or incorporate the introduction into the first post?
Following up on @indragiek's proposal, I'm :+1: on the material at a high level. I don't know if we want to commit to a whole "Intro to RAC series" unless it was already mostly written. I lean toward a process of: write a good stand alone article, then another, and if we can link them after as a series, bonus.
:heart: this idea. I think some simple posts explaining some of the basic operators would be great too. A lot of folks don't understand the basic vocabulary of RAC/FRP.
I definitely want to help out with this where I can.
I'm looking to break this seal. Any thoughts on having an initial article that gives a brief look at RAC 3? Sure, this has the risk of covering things that may still change, but I think there's enough that could be covered that's unlikely to change. The reasons I think a look at RAC 3 is suitable are:
- For those who have already their RAC 2 belt but haven't followed the repo, cover some changes that they can apply in their code (using
RACSubjectoverRACMulticastConnection, considered use ofRACSequence, etc). - For those who are new to RAC, allow them to learn what concepts are being deprecated and optimize their learning accordingly. No sense investing in understanding the
RACStream,RACSignal,RACSequencetriangle. Newcomers might also find it easier to learn 2.0 concepts based on their 3.0 replacements/counterparts (connections -> subjects, commands -> actions). - Potentially, discuss areas where we might like to get feedback?
I think the above are good, but I'd be lying if I didn't also say that RAC 3 just seems like a good topic to get the ball rolling. Speaking for myself, I have other ideas I'd write about, but the other ideas seem like a cold opening.
Indeed, I think I'd benefit greatly from posts that focused on the RAC 3 approach, since I haven't been up-to-date in a while... Particularly discussion of how to refactor things which are currently using replaying, etc.