We already have a blog section (this one). Instructions (and details) of how to post individual threads in the first post of this thread: Elixir Blog Posts
AstonJ
zachdaniel
Creator of Ash
sodapopcan
Ehnnnnn, I have questions and statements regarding this!
I’m sure you have thought all of this through but I want to write it out anyway:
First off, this a lot of text for people simply looking to share a blog post. This isn’t necessary a bad thing, except that within the first sentence I personally find it a bit confusing, specifically:
or, if you want a dedicated thread for each blog/podcast, via Devtalk.com
Does this mean that if I want a dedicated thread I have to post to devtalk.com? This is how I interpret this but would it be ok to just create a dedicated post here on its own? First off, I may just be old, but I don’t even know what devtalk.com is. A quick look at it homepages gives me “meh” vibes and while an endorsement from this forum holds significant weight, in the end it’s just another site I need to create and account for.
Speaking of which:
Ensure your account on Devtalk.com has the same username and primary email as your account here
What if your Elixir Forum username is unavailable on devtalk? Now you have to make an alternate account here which–beyond the reputation/visibility-based consequences–is just annoying. So many accounts!
I’m sure you have thought through allll of this, but it would be so much easier if the barrier to entry was “Make a dedicated thread and make sure you post it in the ‘Blog Posts’ section OR ELSE”
(I’m kidding about the OR ELSE part)
This forum could still get good exposure if writers are encouraged to add “Discuss on forum.elixirforum.com” to their posts with a link to the dedicated thread where there is a high chance there will be comments and if not, at least some up votes.
On the flipside perhaps this has been tried and it created a moderator’s nightmare. If that’s the case then I have no argument here 
Perhaps there is a public place this has all been hashed out before?
Respect for all that you do, mods 
zachdaniel
Creator of Ash
On this topic, I can’t actually seem to follow these instructions.
- On thread creation paste the URL of your blog post or podcast in the TITLE field (once the URL appears in the body field below you can then change the title to whatever you like)
I’m trying to create a new topic in the relevant section, and nothing is happening when I paste the URL of my blog post into the title field. I notice the verbiage in the instructions is “thread creation” but this is “topic creation”. Am I in the wrong place?
AstonJ
Yes all that was thought about - did you read the announcement linked at the bottom of the instructions Calling all BEAM Bloggers! (it has all the details).
The Devtalk system is only temporary, when we move to our custom platform everything will be on site (you’ll be able to hide certain types of content from certain people, certain types of threads will be prevented from dominating the forum, etc)
@zachdaniel, you were on TL0, I’ve manually upgraded you to TL1 so it should work now 
sodapopcan
Nope, but I have now and yes, it explains everything!
Awesome, thanks Aston! Sorry for the long ping.
martosaur
I feel like I had this discussion enough times to put my thought into writing. It’s totally ok to repeat yourself (in tests).
sodapopcan
Next time you are tempted to create a test helper, think twice. Maybe it makes total sense now. Sure, it’s just one click away… No! Stop! People don’t open test files because they just feel like doing it. They do it because a test fails, and by this time they’re already annoyed. Not only do they not want to read more than one test at a time, they will actively avoid doing so! Every function that’s defined somewhere will make their eyes roll. Every setup they need to scroll to will make them angry. And if their rushed fix to a shared setup breaks another test? They may just delete it, because code reviewers have even less incentive to read it.
“If someone is reading this code, they are already annoyed” is a metric I think about a lot in terms of abstracting/extracting code and I have a very hard time articulating it to people. A lot of what you’ve written applies outside of testing AFAIC. I have come to really detest not only excess test helpers but excess helpers in general.
One simple example is that when it comes to constructing options to be passed to a select input, I have lot of this in all of my projects:
foo_options = Enum.map(foos, &{&1.name, &1.id})
Of course we could extract this to a helper:
def make_options(schema), do: Enum.map(foos, &{&1.name, &1.id})
This sucks, though. Not only is the “name” default hidden (even if the most ubiquitous), but non-annoyed readers are going to have to make a jump (another metric I think a lot about) to be confident they know what’s going on.
And now crap, this one place uses a different field, so now we have to introduce an option to the helper:
def make_options(schema, label_field \\ :name) do
Enum.map(foos, &{Keyword.get(&1, label_field), &1.id})
end
…and what if the id field needs to change?
Anyway, it’s so much simpler and more readable to just call Enum.map(foos, &{&1.name, &1.id}) everywhere. If the API for the select dropdown ever changes, I will gladly pay the one time cost of having to manually update everything (tests help there). This is just one example—I generally write a fraction of the helpers I used to. Same goes for extracting constants.
In any event, nice article.
derek-zhou
“excess” is subjective. I have different thresholds for same module private helper functions and public helper functions collected in a separate module. For the first kind, anything that make the logic flow nicer is good. For the second kind the bar is much higher: it has to be a good abstraction as well.
sodapopcan
Ya, to each their own always, I just hate ending up with a massive bag of one liner helper functions. And of course small single-use private functions are always a thing, but I think that has been discussed enough on this forum. But I always have to mention the following single use private function (in a very small file) in a Ruby project I worked on years ago:
def raise_unless_user_valid
raise unless user.valid?
end
sigh