>People writing Rails apps are developing web-apps. Writing HTML is part of the skillset, and of all the things in a Rails app, really not the most difficult, boring or inefficient ones.
I don't think of Phlex as something that lets me get away from writing HTML. I see it as a tool that allows me to bring all my experience and skills of writing clean and well organized Ruby code to the view layer. Am I repeating this same bit of markup frequently? Let's extract that out into a method. Are these two pages basically the same, only differing in one section? Perhaps they should share a common base class.
When I first started using Phlex, this wasn't even on my radar. My thought was that it was just a HTML builder DSL in Ruby, so what? The "so what" didn't hit me until working with it for a while. All my views are now Ruby—not text files with bits of interpolated Ruby. And in the 15 years I've been writing Ruby, I've picked up some skills at keeping it maintainable and readable. Skills that I can now apply to the view layer in a way I never could before.
So all of that is to say: I think I understand the reservations you lay out, and I had some of them as well. But I think there is more under the surface if you ever have the opportunity to give it a chance.
And just real quick, regarding this:
> you're [...] truly in trouble when (not if) the gem gets abandoned.
Phlex is sometimes described, somewhat tongue-in-cheek, as a string concatenation toolkit. At its core, it just builds strings. It is unlikely to stop working unless Ruby has some major changes. It is possible that the phlex-rails integration could go stale after a few Rails releases, if it was not being maintained. As long as Rails can send a string response, Phlex will remain usable.
Just chiming in with my one data point of personal experience: I've primarily used Gmail for all of my email needs. I heard about Migadu several years back and decided to migrate over and give it a try. I was shocked at how completely inundated with spam my inbox was. They had a spam filter with a tunable threshold and no setting on that filter worked well for me. Even on the highest protection level some spam was still getting through, and tons of my actual mail was winding up in spam; which made wading through my spam folder multiple times a day a requirement. Compare that to when I was using Gmail, I didn't even really think about spam. My non-spam email almost never ends up in the spam folder, and I basically never get unwanted email in my inbox.
So after about 6 months of dealing with spam, I went back to Gmail. It's a minor ordeal to move email providers. I'd be scared to move providers without being able to see how well their spam filter works.
As an aside, that would be a nice capability (no idea if it's possible): a way to have your email mirrored to another service to test it out.
Your mail service looks cool though! If I hadn't already been burned I would be more inclined to give it try.
Can you elaborate more on the feature you would like? I have no problem building a solution from scratch if it comes in handy.
Also we use Bayesian filtering, rbls, dbls, rate checks, the whole 9 yards. We haven't had much complaint about receiving spam. Ik you said you've been burned but I'd love for you to give us a shot so I can see what happens and possibly improve.
I don't know if what I'm imagining is technically possible. But it would be cool to be able to have my email mirrored to two different services. One email address, email shows up in Mango Mail and my Google Apps email. Then I can evaluate Mango Mail's spam performance against Google's to see if it's good enough for my needs.
If I get up the courage to try again, yours will be my first choice :)
Hmm... so just off the top of my head, I'm thinking one service would have to forward to the other. Only problem with that is that the sending server would now be the relay and not the original sender. Since MX records only account for using one service, there would need to be some sort of intermediary to do this. Possibly have mail delivered to a common server which then sends it to both Mango and Google (giving each the same odds to detect spam).
If you do end up trying it, feel free to shoot me an email either at contact@mymangomail.com or my personal, steve@mymangomail.com
It's artificial if the entity loaning you the money and setting the rate has no associated risk.
If I loan you money there's risk you won't be able to pay me back. So I decide what interest you would need to pay me for it to be worth it for me to take that risk. Lots of other people do that, and you get a "natural" rate of interest as you call it. Everyone offering you the loan has skin in the game.
But if the entity that prints the money says they'll loan you money, it doesn't matter to them if you can't pay it back. They set the money supply. If you don't pay back, they can take the value from everyone dealing in their money by printing more. This lack of risk allows them to undercut the rates of entities who would be taking on risk. Now you have an "artificially" low interest rate.
The app watches Elon's twitter account and sends a tweet to him as a reply as soon as he tweets. We send user provided tweets, prioritizing tweets that have the highest bounty paid on them. The bounty can be added to by anyone, using the bitcoin lightning network.
Hey HN! Thanks for checking this out! Sorry for the crazy permissions requirements, unfortunately I don't think there's any way around them. I also don't think there's anything I can do to assuage a highly skeptical person that I'm not a bad actor. But the code is here for anyone interested enough to look at it: https://github.com/willcosgrove/retweet-rip
The app also does not save the access tokens it gets back from twitter. They get thrown in a background job to be worked on, and once the job is done the access tokens are forgotten.
Unfortunately, permissions are only configurable on a read only or read/write basis. Since this app changes settings, it has to have the read/write permissions. I don't save access tokens, so it reauthorizes every time you click enable/disable. I just posted the code on github for anyone who's interested. Here is the link to the code that messes with your twitter account: https://github.com/willcosgrove/retweet-rip/blob/master/app/...
At most you can encapsulate the world you have perceived (+ stuff you imagine) which is much smaller then the whole world, and even that is a stretch, because we have limited computation available to us, so there is a lot you might be unable to account for due to limited time for accounting.
I don't think of Phlex as something that lets me get away from writing HTML. I see it as a tool that allows me to bring all my experience and skills of writing clean and well organized Ruby code to the view layer. Am I repeating this same bit of markup frequently? Let's extract that out into a method. Are these two pages basically the same, only differing in one section? Perhaps they should share a common base class.
When I first started using Phlex, this wasn't even on my radar. My thought was that it was just a HTML builder DSL in Ruby, so what? The "so what" didn't hit me until working with it for a while. All my views are now Ruby—not text files with bits of interpolated Ruby. And in the 15 years I've been writing Ruby, I've picked up some skills at keeping it maintainable and readable. Skills that I can now apply to the view layer in a way I never could before.
So all of that is to say: I think I understand the reservations you lay out, and I had some of them as well. But I think there is more under the surface if you ever have the opportunity to give it a chance.
And just real quick, regarding this:
> you're [...] truly in trouble when (not if) the gem gets abandoned.
Phlex is sometimes described, somewhat tongue-in-cheek, as a string concatenation toolkit. At its core, it just builds strings. It is unlikely to stop working unless Ruby has some major changes. It is possible that the phlex-rails integration could go stale after a few Rails releases, if it was not being maintained. As long as Rails can send a string response, Phlex will remain usable.
reply