rubynerd
This article is the missing piece explaining why:
1. Shopify, allegedly, "specifically demanded that at least one of the RubyGems maintainers, André Arko, be excluded from returning to the project."[0]
2. Rafael França, a member of Rails Core, publicly listed concerns[1] about "competitor tooling"/"admin trust" r.e. rv.
Both are components of Joel Drapper's post that gave me pause on my first read, as these statements aren't something said without basis. That basis being correct or not is another matter, but I wouldn't expect either Shopify or a member of Rails Core to have such concerns simply because they don't like someone.
Personally, I don't come away from this article with the sense the author dislikes André, just that there's perhaps more rationale coming from a camp that's largely not said much so far.
Looking into the crystal ball of future predictions, the battle lines we're going to see in the Ruby community will be based around the acceptance or rejection of some of the allegations here about Ruby Together's spending.
I recall Ruby Together advocating for personal sponsorships in addition to corporate. It's one thing to be treating Apple adapters as disposable HB pencils & buying dinners on the company card if companies are funding you, but it's a different matter of fiscal responsibility when you're potentially spending personal donations.
Coming out of this, I'll suspect everyone will align that open-source contributors should be paid, and companies should in some way support open-source, but we'll see fractures over if André's alleged behaviour is acceptable.
I'm looking forward to someone/something assembling an entity which is trustworthy & responsible. If Ruby Central can't be that entity, we'll need a replacement.
[0]: https://joel.drapper.me/p/rubygems-takeover/#:~:text=Shopify...
[1]: https://bsky.app/profile/rmfranca.bsky.social/post/3lz7alpob...
---
Additional reading if you haven't read it before, "Nothing like this will be built again" about Torness: https://www.antipope.org/charlie/blog-static/rants/nothing-l...?
Previously posted several times: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
The scariest part of this pricing split is that Stripe seems to be determining the fee "based on the information available from card networks at point of capture", instead of being directly told what the card type is, and even allude to this determination being potentially incorrect.
This gets even more frustrating when you think that business spend is on average higher than personal/consumer spend, so charging a higher fee for this is just a triple whammy.
It's easy to crucify Stripe for this, but this is probably a product of a cost review they're undertaking as part of IPO/next round prep (if The Information is anything to go by). We need a new Visa/Mastercard.
[0] https://support.stripe.com/questions/what-s-the-difference-b...
With this article shining yet more negative light on the program after the Facebook/Google spying-on-the-internet-access-of-kids debacle effectively shut the Enterprise program down, the MDM space will be even harder to innovate in, considering no startup will ever meet the required bar for signing up for an Enterprise account.
The experience is a little rough with the redirect, and I'd love it if I could put an email somewhere for a reminder when it launches. Otherwise though I'm really looking forward to ordering soon!
Do you have an estimate of when the Framework Marketplace will be available for UK customers? Currently Marketplace links redirect to the UK homepage, and is only accessible after manually selecting "United States" as a country.
I would imagine Spotify access would be heavily affected by such a block, considering their sizeable GCP deployments.
One day I'll overengineer something to solve this, but for the meantime it's "ssh statichost -- sudo kill -s HUP 947" every so often. Thanks for reminding me, much appreciated!
I'm not hopeful for any change in these sort of review processes without any legislation changes, but it would be a truly tragic state of affairs if it were to escalate that far.
Regarding Stripe's support: I emailed last night to confirm how to delete a user's card when it's represented as PaymentMethod, and in reply I received a link[0] to the cards/delete API documentation (which, in case you're not as steeped in PaymentMethod's as I am, won't work because the two objects are fundamentally different).
Given this rather lacklustre handling & having also been on the receiving end of someone trying to fraud the company I'm working for, I highly doubt someone who is asking for reconsideration after receiving a fraud ban would actually receive an escalation via the front-line agents manning [email protected], and if they could, the actual legitimate bans that Stripe no doubt needs to put in place would simply abuse that channel and waste everyone's time.
I appreciate it's a really challenging balance of trying to provide an escalation/appeals process that won't be abused itself, and by comparison Stripe's approach of direct-founder-contact seems easier than Apple, as if your developer account application is rejected[1] you have absolutely zero recourse apart from going H.A.M. on Hacker News & hoping the community helps you out, whereas in this case there is a magic button that starts an invisible and unaccountable appeals process, that ultimately resulted in another rejection.
The only "solution" (if any) I can see to counter the negative experience (& associated PR) would be involvement in the appeals process, where you are allowed to effectively "state your case" via video call or submission of evidence, but this draws a thorny parallel to the judicial system, and I doubt Legal would sign off on such a process.
This is a problem that impacts basically any kind of appeals process, and Stripe's not alone in suffering from it, but that perspective doesn't help the dozens of founders that don't have the connections to sort this issues out in private, and are burning the attention span of Hacker News in the process of unblocking their businesses. Front-line support also isn't the answer, unless specific processes can be put in place to handle rejection escalations and get them into the eyes of the right people.
---
[0] https://stripe.com/docs/api/cards/delete
[1] Long story short: to use Apple's Mobile Device Management APIs, you need an Enterprise developer account, which thanks to The Verge & gambling apps skirting the App Store, isn't possible unless you went to Stanford with a future Apple PM. Admittedly, the chances of an Apple executive personally addressing this if I were to email is statistically quite low compared to emailing you.
If someone from Apple is reading this & would like to pre-empt the classic "Apple screwed me" Hacker News post, do feel free to email me on [email protected] and I'll happily brief you on The Great Saga of Enrollment 4HZY7VX69S.
Imagine if you're running a web store, and you want to go to a conference or convention or something and start selling your stuff there. All of your tools still work, all of your reporting still works, and crucially your accounting flow remains identical.
The customisation options are probably up in the air right now - I imagine developers won't get the ability to customise the UI available on the PIN pad in the first release, but I imagine that's where they want to get to.
We had this problem at work: a Sinatra app that had pieces and pieces of ActiveSupport bolted on, and it got to the stage where we needed a beefier database than Redis before the CTO eventually generated a new rails app and transplanted the Sinatra app on top of it.
It's all well and good saying "use Sinatra", but when you get to the stage where you're adding ActiveRecord because it's the most mature ORM out there, it's usually late enough in the game that you're actually writing a poor excuse for a Rails application.
* Create an unprivileged account & set a password that you don't need to remember -> sudo adduser git
* Add your public key from your laptop to the unprivileged user's authorized_keys file -> sudo su git; cd ~; mkdir .ssh; vim authorized_keys - then copy and paste your id_rsa.pub to that file
* Repeat that for all public keys on your engineering team
* In git's home directory, git init --bare <name of repo>.git
* On your local machine, git remote add doomsday git@<DOOMSDAY SERVER HOSTNAME>:<NAME OF REPO FOLDER>.git
* git push doomsday --all
* On colleague's box, git clone git@<DOOMSDAY SERVER HOSTNAME>:<NAME OF REPO>.git
Let me know if there is a better way of doing this, or if it's monumentally screwed somehow.
* If I wanted the build server to point to our internal git mirror, I would configure it to point to our internal code mirror, but I want it to build off of Github webhooks.
* The "eggs in the basket" analogy is probably best saved for a situation where I'm dependant on a cloud service, such as Twilio.
* I would expect an amateuristic private server to have better uptime than a monolithic service such as Github because there are a lot less moving parts, and in our case, a lot less people doing things with it.
* The "company impact" of Github going down is next to nil. It's one o'clock in the morning on a Sunday, I'm eating string cheese, and I feel like being productive. The company is not paying me for this, and have encountered zero losses from it. We have a very simple mirror which we can use to push code to production if Github goes down, which we have never actually had to use.
Personally, I find the "keep a torch in every corner of every room because for 15 minutes last year the power was out" attitude to life is a bit over-rated, and you're planning for an edge case. I'd much rather remember where the torch is and learn to walk in the dark.
I first attempted to redo the README for a service I've just open-sourced, before realising Github is down.
Then, I attempted to fix the company CI server (OOM errors because of Carrierwave needing more than 500MB of memory to run 1 spec in, for some unknown reason), which failed because it couldn't check out the code.
After giving up on that, I attempted to install Graphite to a company server, where I hit another roadblock because the downloads are hosted on Github, and so I had to use Launchpad, which I had an allergic reaction to.
Also, when I was shelling into the server, oh-my-zsh failed to update because, you guessed it, Github was down.
Still, shouts to the ops team in the trenches, we're rooting for you.
Although, it still kills the advertising cash cow.
Please try going native, the performance increase would be in the order of magnitudes.
Are you the only one working on the app?
I am admittedly on v.3.0.x, but the version previous behaved the same way, so I have little hope for future versions.
I must admit, the Tumblr app is one of the few apps that make me want to throw my phone against a brick wall.
I wouldn't call it a 'negative value add' because it means you don't have to babysit a server somewhere, assuming you want to add scheduling onto a Twilio action (call/SMS).
If you took Iron.io out of the equation, how would you schedule the Twilio call? I assume you mean via cron, which is all well and good if you want another server/script to babysit.
That said, I haven't used anything from Iron.io since I've left, and I've written scripts which use a loop, sleep and two if statements to 'schedule' a Twilio call.
So when you hover over, a tooltip appears underneath the icon?
I know, there is a feature that I thought was worth quite a bit, and I didn't include it but based the pricing model off of
I'll attempt to fix this soon, it's currently late here and I'm very tired :(
EDIT: OK I won't disable SSL