Hey folks! It kind of feels to me like a 1000 message long post for blog posts isn’t really ideal. I’m happy to be wrong, but it feels like these categories should each be its own forum, and we can make a new post per blog post. Thoughts?
7 Likes
Yeah, not conducive to discussion of the post.
@moderators what would you think about making just a “blog posts” forum to use going forward? we can use standard tags to delineate subject matter and categories etc.
or maybe even more generic, like “external content”?
2 Likes
This would be nice as then the posts could link back here to act as the “comments section.”
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
Yep. You’re right. It’s plain as day. Sorry for the summon 
1 Like
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 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 
1 Like
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?
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 
2 Likes
Nope, but I have now and yes, it explains everything!
Awesome, thanks Aston! Sorry for the long ping.
1 Like
I feel like I had this discussion enough times to put my thought into writing. It’s totally ok to repeat yourself (in tests).
7 Likes
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.
2 Likes
“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.
2 Likes
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
3 Likes
Write-time is the honeymoon phase for a test; it’s when it’s being cared for the most. Unfortunately, it’s all downhill from there. They will never see the same treatment again, not even from their own creator.
This struck a chord (and made me laugh out loud 
). Nice write-up!
4 Likes
Ah tests, I always kept it in the back burner. But I kept reminding myself to at least give an effort on tests.
Nice writeup!
1 Like
I have published an article with an extensive overview of Papercups, a feature-rich open source customer service platform with real-time chat capabilities.
Papercups is built with Elixir, Phoenix, Oban stack.
The article covers:
High-level architecture of the platform & the main data model
Handling communication with customers across 7 channels in a uniformed way and figure out to which ongoing conversation it belongs
How to receive emails via AWS SES- How to sync emails from GMail
How to receive SMS via Twilio- Embedded Chat Capabilities via Phoenix Channels & Presence
Usage of Slack/Mattermost as reply channels
Webhook and Lambda Function functionality to extend the existing functionality- Advanced browser session tracking and reply
Reporting, analytics, billing strategy
Papercups is an excellent example of how to build a SaaS platform in a radically simple way.
Let know if you find this useful in the comments below 
3 Likes
Nice write up! @roma-glushko did you work on Papercups or only studied from the outside?
I really enjoyed the commentaries you made on certain decisions made (the colorful call outs).
Thanks for sharing!
1 Like
I wrote a quick refresher for myself on Logger Handlers vs Backends for the time when I inevitably forget what is what List of True Things About Elixir Logger Handlers and Backends | Alex Martsinovich
4 Likes
