We are gym management software serving primary martial arts schools. We are looking for writers to contribute to our company blog with topics relating to martial arts instruction, marketing for gyms and the business of operation a martial arts school.
Stripe and Paypal are 2 different payment options. It's not either / or - you can have both available for your users. Paypal users can chose Paypal, while the rest can enter use their credit-card without leaving your site - which is huge plus, considering Paypal's relatively high friction process for credit-card payments.
No offense to the writer, but it seems to me he doesn't really understand web development. In 99.9% of web applications, the bottleneck for scaling is the database and not the language. Web application processes are generally not CPU intensive and are short lived, something PHP handles very nicely.
On the other hand, PHP has a huge list of existing resources, libraries and excellent documentation and community.
Look over at the language used by the largest sites on the Internet, and compare the number that use PHP to the number that use Go. Not saying Go can't handle those applications, but obviously PHP was used in scale effectively on many occasions, while Go hasn't proved anything yet.
Go documentation is very good, the standard library is extensive, and it has a very active community, but it does lack certain libraries that web developers might find attractive, e.g. a comprehensive ORM.
Insinuating PHP is better because it's deployed in more places is silly.
Stop reading between the lines, I didn't say PHP was better as a language. What I was saying was that trying to convert PHP developers into Go programmers with those kind of arguments shows a basic lack of understanding of how web applications work, or what is the real strength of PHP.
Most web developers who read Hacker News don't host their stuff with a hosting provider that doesn't even provide shell. With Go you just need to be able to execute a binary.
You sounded a lot like Go hasn't proved it's viable for "web scale." It has. Is it as widely deployed? Of course not, it's new.
I'm not sure what strength of PHP you're referring to--I'm assuming the ubiquity with shared hosting providers--but it's not even that great of a language to interface with databases, which was your example before.
Not arguing for Go particularly, just arguing against PHP. Its ubiquity is basically all it has going for it, but yes, that's a big deal.
Again, you assumed wrong. Makes me wonder what your actual experience with PHP is. The strength of PHP is its focus on the web environment through features and functions that make it simpler to develop in that environment, that have be implemented in code on most other languages. In addition, the huge amount of available mature libraries for a variety of purposes and the large community that supports it, is something I really find hard to believe Go can compete with. Saving development time with mature code is much more important than learning a language that doesn't provide much tangible benefits for the web environment.
I've used PHP for 15 years. You keep making these "I-know-better-because-I-use-PHP" statements, but ironically you probably have never even touched Go. Give it a try. Don't be the guy who hates anything that's new.
("Poor library support" is a terrible argument for PHP vs. Python, Ruby, or even functional languages with respect to web development too.)
You're the one who's doing the hating my friend... you keep finding hidden messages in what I write and generally piling up on PHP without good reason. I never said anything bad about Go, or bad library support in other languages, just not agreeing with the article on comparing PHP to it where PHP is (in my humble opinion) a very strong option already.
I pile up on PHP because it's a shitty language, and basically the only argument for using it nowadays is that it's relatively ubiquitous among budget shared hosting providers. I don't think I ever tried to hide that I hate it.
I meant as widely deployed as PHP. I'm not sure that that is a measure of anything at all though, except that itself. It's certainly not an indicator of any kind of code or API quality.
A type of web app for which Go shines is ones that have data already prepared when the user arrives. Database retrieval and update can be handled by processes that aren't dependent on the user. This can make the app super fast; e.g. langalot.com.
The Minfraud service I mention in the article has an automatic phone verification system. You can use it when the risk score crosses a certain threshold
I am the author of the article - thanks for the positive overall comment. I agree with you to a point regarding "buyer's remorse" - perhaps I didn't word it strongly enough.
For some products, what you say makes perfect sense, but for us, since what we sell are code licenses, you can't 'undo' what you learned by using the code. Regardless, we offer 14-day money-back guarantee, and people still sometimes choose to take this approach - issuing a chargeback on their transaction, when it's obviously not regular fraud.
We usually try to communicate with the buyer to understand why he issued a chargeback, and in a few cases we managed to resolve it (so I would never suggest going with your first approach - always try and contact them first). Otherwise we just "eat" the cost and get on with it.
Loved the write-up. If you expand outside paypal/ccs into other methods like direct debits (common for Germany) I would be curious to hear similar stories. Accidental chargeback rates are way up on direct debits so any stories for dealing with that efficiently would be very interesting.
One thing I didn't really see was "previous successful purchase" - that should be a strong indicator of "not fraud". Even if other details look dodgy.
Not sure if "previous successful purchase" is enough of an indicator. If someone can hijack a Paypal account or obtain sensitive credit-card details, you should assume he can also hijack an account on your service.
Glad you liked it, we had to learn most of this stuff the hard way :)
Yeah they for sure can. They just don't tend to bother I think. Hijacking an account and the payment method used to pay on that account to go with it is a lot of work to do something you can do with less work.
May be business dependent tho. I guess selling source code means the people interested in defrauding you are fairly tech savvy too.
If you expand outside paypal/ccs into other methods like direct debits (common for Germany) I would be curious to hear similar stories. Accidental chargeback rates are way up on direct debits so any stories for dealing with that efficiently would be very interesting.
Would you mind expanding on this, please? We're looking at different payment possibilities for a start-up and direct debits is one method that we are considering. This is the first time I've heard of a much higher chargeback rate on such transactions, though.
If you are using direct debits you have no way of pulling the money directly from the account - you will always have some serious lag (day or two at least, often more). In that time you don't have a hold or similar on the funds, so either you delay giving product to customer or you have a few days where you trust him to actually have the funds available when your claim hits his bank. If he doesn't actually have funds at that time you effectively have a chargeback (no funds were actually available to take in the first place). Usually these are honest mistakes, especially if you do recurring billing that the customer may forget, but it's costly and time consuming to explain what happened and have the customers pay you again for something they actually want.
Thanks, that makes a lot of sense. Innocent mistakes we can deal with. I was more worried about a high rate of formal disputes where customers might claim we took money fraudulently. It sounds like a track record full of that sort of thing can make it harder to get good terms in the future, and I didn't see why that should be significantly higher with one form of payment than another.
Traction is 100% about persistence. Nobody cares about your code. You need to constantly approach bloggers to write about you, post in forums, online communities and link sharing sites such as this, generate content and optimize your visibility on search engines, and mainly just keep plugging at it until something sticks.
Also, not every service can have organic traction. Some services are just not social / sharable (I would even say most services), and must rely on tried-and-true user acquisition techniques - ads, affiliates and so forth. It's also possible that your service is not of enough interest or use to people who are not friends and family (just putting it out there).
It's not the hourly rate, it's the total cost and quality delivered. Try bidding on fixed priced projects - while you'll still likely to submit higher bids, the difference is not as big as the hourly rate - since an experienced programmer can do more in less time.
Represent yourself with class and show a portfolio of quality work. Not everyone goes for the lowest bidder, and you definitely want the clients that are looking for quality. Do you really want to work for someone who expects you to work for 12$ / hour?
We are gym management software serving primary martial arts schools. We are looking for writers to contribute to our company blog with topics relating to martial arts instruction, marketing for gyms and the business of operation a martial arts school.
Check out our existing content to see what kind of voice we are looking for - https://www.maonrails.com/blog
Send us a few writing samples and your rates through our contact form.