>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.
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 :)
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.
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/...
The Agency I work for built a tool call ElementCSS for the 2013 Rails Rumble. It's currently not under active development, but we're going to begin work on it soon to turn it in to a more usable product.
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.