Hacker Newsnew | comments | show | ask | jobs | submit | waleedka's comments login

Nice idea! But it didn't work for me when I tried to login to my site. It opens a Facebook auth popup for the login.

-----


Just because you can hack another app doesn't mean you should. You're just enabling another form of spam. There are more interesting things you can work on. Don't be that guy.

-----


Just having some fun. One of our out of state interns was playing on tinder (doesn't really know anyone around here) after a long day of work and we thought it might be fun to see if we could automate the process. No harm intended; just blowing off steam.

-----


For what its worth, I think its a funny/cool project that you guys were obviously just messing around with. A lot of these top comments are taking this much to seriously. Cool execution guys!

-----


Thanks for restoring sanity :)

-----


It was also a bit of a teaching moment. I was trying to show our intern how to use http://www.cycript.org/ for fun at night and he happened to have the Tinder app open. We love hacking things.

-----


Same with Google+. I always get Hangout invites to the wrong Google account, and then we spend 10 minutes trying to get the call started and eventually switch to Skype.

-----


A factor that's usually forgotten is the developer's time. App Engine saves you A LOT of time compared to other solutions.

* Once you write your app the App Engine way, it scales automatically. You don't need to re-write periodically to accommodate growth, add replication, shard your data, ...etc.

* Data is replicated to several servers and data centers. You don't worry about losing data due to a hard drive crash.

* If an instance crashes, or a whole datacenter dies, your app keeps running.

Basically, measure how much time you send on non-code activities. App Engines saves you 90% of that.

-----


"The App Engine way" involves writing a lot of things from scratch that normally you wouldn't have to, and spending a lot of time on kinds of optimization that you are unlikely ever to need. This offsets that perceived benefit in terms of developer time.

You could argue that it's good to spend this extra time because it makes your site more scalable. But if you ever reach the scale "the App Engine way" becomes relevant at, you are likely paying an order of magnitude more than you would if you bought dedicated servers. For all smaller cases, you are prematurely optimizing for scalability.

App Engine's reliability is easily overstated. App Engine has had a long history of issues with their services like datastore. When datastore does not function, there isn't any reasonable way to build a backup storage system because the platform is so restrictive. Frankly, backup services are cheap, and there are plenty of hosted database services if that's all you need. Ones which don't lock you in forever.

So, yeah, sites built on App Engine do go down for various reasons and still have to be monitored just like anything else. Except that you can't use any of the usual tools because the platform is completely unique and the underlying software is proprietary and completely secret to you as a platform user.

App Engine apps realistically only run on Google's servers. So even in the best case, you must have a lot of pure faith in Google. Because if you have reliability problems, problems with the platform's restrictions, problems with the terrible support or if the price skyrockets again, or if the platform gets wound down... you will be absolutely forced to rewrite your whole project to move it off of App Engine. You really won't have any idea that this is going to happen until man-years have already been invested.

-----


It's great for standalone, spare-time projects that don't need 100% uptime or monitoring, though. I have low-traffic websites I haven't touched in months or years and they're still running fine. On anything else I would probably have shut them down by now due to some forced upgrade or other.

You pay a bit more developer effort up front (weeks, not years, for these projects) so you can walk away, but that's when I'm actually interested in working on the code. Migration is a non-issue since I don't plan to migrate. If I have to do any real work at all, I'll probably shut the site down anyway.

-----


You don't succeed by being a jerk. But if you're a smart entrepreneur, you may succeed despite being one.

-----


Website Screenshots: http://www.bitpixels.com

Serves 40 million images a month. It can generate small thumbnails or large screenshots of full-length Web pages. It runs itself and I rarely touch it, but I don't have time to improve and monetize it.

-----


Wow .. that is something I have been looking for quite some time. In the meantime I decided to make a custom solution, but yours seem to work way smoother.

- Do you cache images? If so, how long are they cached? - Are there any restrictions, beside adding the attribution link, for commercial usage?

-----


Thank you. I cache images on App Engine. I have a simple API to force cache eviction (email me if you need it). There are no restrictions other than the attribution link.

-----


40m images a month as a free service? How much is that costing you to keep up?

-----


If you don't sell it, please open source this. :-)

-----


Please email me traffic details and more info. Would be very interested in taking over, or working with you, on this project to grow it to that next level.

-----


Do you make anything form it now? What are you hoping to get for it? - and what stack are you using?

-----


It's two parts: An App Engine/Python for the UI and user registration, and a Linux server for image capturing (Python, Javascript, RabbitMQ, ...etc.). At first we used popular libraries like Phantomjs, but eventually had to write our own to scale better.

I'm experimenting right now with moving the image capturing code to an App Engine managed VM to simplify things and make it scale easier.

-----


Which library are you using for image capture? Been using webkit2png ( https://github.com/AdamN/python-webkit2png/ ) for a personal project, but I'm interested to hear your experiences.

-----


Could you mention why you stopped using PhantomJS? Also, how are you supporting flash?

-----


Could you please elaborate on what your own implementation turned out to be?

-----


How do you make money from it right now?

-----


I don't yet. I needed a service like this a while ago and the existing ones were too expensive for my level of traffic, so I built one and then decided to open it up to others as well. That was years ago and it grew over time. I never got around to building a payment system for it. It was always something I wanted to do but never had enough free time to do it.

-----


I'll do that once there are 2048 versions of them.

-----


I was pleasantly surprised by these results. Language adaption is not linear, it follows an S curve. So while 22% are on Python 3 after 5 years, we can expect to reach 80% much faster.

-----


Then you're punishing the good guys.

-----


The good guys don't send me mail I didn't ask for.

-----


Yes, login-to-unsubscribe would be much more palatable if it were for things I actually opted in to. If I did not subscribe, then it should be easy to unsubscribe.

I'm looking at you, LinkedIn and Twitter. I've unsubscribed from about three or four waves of your bullshit. No, I don't care about what I might have "missed on Twitter". I didn't subscribe to this, you spamming fucks.

-----


No, but they send you mail that you inadvertently asked for, and mail that you initially asked for but have since decided that you no longer want.

-----


"mail that you inadvertently asked for" IS spam.

Personally I give them the benefit of the doubt and try to unsubscribe with ONE click.

There is no good reason to make people click more than once.

-----


Symphony makes $2500/month (http://www.symphonytools.com). Launched 4 months ago. Back in December, my co-founder and I spent 3 weeks brainstorming and wrote 25 business plans for 25 ideas. And then chose this one. Started building it in January.

It's written in Python. Hosting costs about $700/month on Google App Engine. It doesn't cover our costs yet, but it's growing. Hardest challenge so far has been to find ways to let the world know about it.

-----


Why are you still on GAE if it costs that much? I learned Django and migrated my projects off GAE a year ago. It was rather painless to learn the bits of Django needed to replace GAE, and looking back it was a great move.

-----


I think of it as paying a little extra to outsource the boring parts of my job to Google. I don't worry about sharding, load balancing, replication, ...etc. I've done those in the past, and it wasn't that exciting. I like spending my time on code, and it lets me build things faster.

App Engine has it's disadvantages as well. At one point I used typhoonae (open source framework that let's you run you GAE apps on EC2) and was about to switch, and then decided against it.

-----


How many users do you have for $700 a month on GAE?. My game Neptune's Pride that also makes about $2500 a month and has about 1000 - 1500 DAU only costs around $100 a month.

-----


Only about 200 DAU (3K MAU), some are paying and the rest are on a 30-day free trial. But we do a lot of processing for each user. For example, we have a unified inbox for all your mentions and messages from all your social networks, so we pull a lot of posts on a regular basis. Our database has 3.7M records, and a total size of 15GB (8GB for data + 7GB indexes).

I expect the cost per user to go down as the percent of paying to trial users goes up. Trial users stay for 30 days, and then most of them stop. But paying users continue using it much longer. Also, there is a lot of room for optimization, which I'll get around to doing later, once the key features are in place.

-----


Could you easily move out of GAE? I made a site on that platform a couple years ago for fun, and would get anxious every time I'd get an email from them with terms of service or API changes.

-----


Not too easy, but not as hard as people expect either. The App Engine SDK is open sourced. This is the layer that connects your code to Google's infrastructure. There are a couple of projects that have taken that SDK and modified it to connect to MySQL, MongoDB, memcached, and so on. They allow you to run your GAE app on your own server, without changing your code. I tried typhoonAE a while ago and managed to get my app running on another server with about a day of work.

-----


Hosting SHOULD NOT cost that much with GAE. What's the bulk of your cost (I'm guessing DB writes)?

-----


I was able to get my GAE costs way down by focusing on minimizing DB writes. Some tips:

- Instead of storing an array in the database directly, store it as a json string. storing an array uses a DB write for every array element.

- Don't index things if you can get away with it (indexing doubles writes).

In my case I was using about 600 writes for every user action when I only needed two. This may be common knowledge, but I was pretty surprised that storing arrays was costing me so much.

-----


I minimise costs by using a mix of GAE and AWS: Host the main application on GAE but for background services use AWS. E.g I use AWS SES for mails and S3 for storing uploads and blobs.

Also storing objects that don't need indexes as pickled blobs in a parent model helps a lot. The advantage over JSON is that you don't need extra code to parse, (de)serialized and validate the object.

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: