Seems like a tricky situation, I assume you tried donations and it didn’t work..?
OT: Oh god that rog video in the website’s home, I hope you know people will assume it’s silly stuff
I have not actually. Do you think patreon is a good choice? Since the costs are ongoing.
RE: rog, yeah i know, i thought it might be a little funny. My user base is teenagers btw.
You’ve jumped straight to caring about money without checking to see if you care about something/anything else first. You don’t ‘want to monetize because..’, you are hitting some limit on something being able to progress or sustain itself within some parameters which have come about because you care about something.
What is it that you want to progress or become sustainable? In that context what are your values: the things you care about? What are all the available options for allowing progression/sustainability inside values that are important to you?
My goal would be to financially justify the costs and my time spent on running the project.
Im not particularily interested in the actual problem space any more. I dont have great ambitions for the project because it could be trivially shut down by some news organizations.
Ideally it would be enough to offset the costs of operations (30$ per month) + time i spend fixing bugs and optimizing for scale (the JS client takes multiple minutes to perform a search on 100,000 articles, i dont want it google fast, but under 20 seconds for most searches would be ideal.)
Is the code base pretty modular – could I point it at a lobste.rs clone, and it would “just work”?
It looks like there’s a static baseURL, and changing that should let you use a different site.
source: lines 26-28, https://github.com/Mongey/pinchy-android/blob/master/Pinchy/src/main/java/com/pinchy/android/LobsterAPIClient.java
You can link to specific lines this way
The only way to kill the URL is implement a proper sharing API almost like android, that websites or browsers implement to receive or share URLs.
Not only that but it would need to be easier than copy and pasting a URL.
This is a bit tin-foil, but Google could be pushing for this in the future by making plain URL copy and pasting more difficult or requiring more clicks /tediousness to do it. (Like hiding the URL behind a button you need to click)
This is a tough problem.
JavaScript is very much like C nowadays (correct me if im wrong, my CS history knowledge is lacking)
How did C programmers solve this problem? (With mixing modules from compile-to-c languages)
We didn’t. It’s very similar to JavaScript.
Typically, C and C superset (e.g. C++ and Objective-C) applications either:
Use a few well-understood (e.g. GTK+, ncurses, zlib, et al.) dependencies. The requirements range from requiring (#include <dependency>) and linking to CMake magic.
Use monolithic frameworks (e.g. Boost, Cocoa, Unreal Engine, et al.). They mask most of the complexity from the programmer.
URLs are the lowest common denominator of web pages
There are few common expectations on the web, but one of them is that you can share something by sending a URL.
I foresee google adding a “Share” button to the desktop version of google chrome, much like they have on android.
I enjoy reading gary b content, but seems like he missed the point.
Yes, DHH used exaggeration and rhetoric in his blog – he’s known for it.
The article is almost contrarian for the sake of being contrarian – at a high level they both agree that mocking everything to death is superfluous, and that Tests in general are good.
Couldn’t agree more; I stopped reading the article after first paragraph. :S The whole TDD is good/bad sideshow feels like an election year debate which only benefits the candidates engaged.
I don’t see why DHH should get a free pass for using crappy arguments. I think this whole post is useful but an important TLDR may be the end:
TDD is useful and test isolation is useful, but they both involve making trade-offs. Unfortunately, doing them 100% of the time seems to be the best way to learn what those trade-offs are, and that can temporarily lead beginners toward extremism. TDD and isolation both break down in some situations, and learning to detect those situations in advance takes a lot of time. This is true of advanced techniques in any discipline, programming or otherwise. That is the honest, non-exaggerated, no-lies-involved truth.
part of the problem is someone needs to kick off the discussion – i also see this on hacker news for new stories.
the easiest way to do it is to ask a question in the comments, that’s how you start a discussion
For reference, here’s the latest keynote that DHH presented at railsconf 2014
This seems like the same natural evolution I see in my code.
Is there something wrong with starting with the naive approach?
Seems like if I started with the final product, I might waste time writing code if we decide that an email marketing feature was un-necessary.
I’ve been using TDD for most of my new projects. I found that when I start writing tests for my code, I naturally break it up into testable chunks as seen in the post. Testing EmailSubscriptionWorker is much more robust than mocking the MailChimp object when testing User.subscribe_to_mailchimp and makes a lot more sense.
Looks similar to Google’s project Ara how is this different? (I don’t mean this in a mean way, i’m genuinely curious)
Apparently the projects were created independently, however it appears that Motorola/Google will work with the Phoneblocks community to provide a better end-result.
http://motorola-blog.blogspot.jp/2013/10/goodbye-sticky-hello-ara.html
cards lend themselves better to gestures, which is one of the main advantages of touch screen displays
I briefly went through this a few months ago, but haven’t had time to revisit it yet. If you’re doing heroku, you’ll run into the following issues assuming the codebase nor heroku hasn’t significantly changed since ~Nov2013:
Heroku rails apps still only work with postgres, not really mariadb/mysql
The lobsters source (back in nov. 2013) used some mariadb/mysql specific calls, I sorta tried to fix them here to work on postgres/heroku: https://github.com/seltzered/journaltalk and did a bit more details on it here: https://stackoverflow.com/questions/12427648/mysql-to-postgres-conversion/19624041#19624041 , but the code there is pretty much at your own risk. We ended up setting up a DO instance for future work.
More heroku-ish stuff:
3- If you want to use sphinx on heroku, you can use the thinking-sphinx heroku add-on. I think the cost is ~10/month
4- For ssl on heroku, you’ll also need to setup an ssl endpoint.
tl;dr - double check on point #1 before really trying to use lobsters on heroku. And feel free to prove me wrong on this stuff, I haven’t been doing rails much these days.
what broke under postgres? at the very least, i’ve got the site to boot, and basic use cases seem to work fine (submitting a story, voting)
sphinx is just off for now, no point in having search for a brand new site that’s tiny
SSL should probably be on, we’ll need to get a cert before we launch
thanks for the tips, and the link btw
When you have a product that some people find valuable, then most likely different types of people value it differently. Specifically, you might have teenagers using it to do their homework who probably don’t even have credit cards let alone want to pay for something. On the other hand, you might have grad students using it to put together their thesis (maybe that’s worth a few bucks to them?). Or maybe teachers suggesting it to their students (maybe there’s space in the department budget for a group license?).
Part of doing business development is figuring out who these groups are, how they’re using your product, how to find then, and how much they’d be willing to pay for it. You could try shoving a $1-3 cost on the Chrome extension and see if it’ll cover your costs without killing your userbase, but if the expenses are growing quickly as you say then it may not be enough.
If you have an organization in sight (the speech competition), then maybe consider working with them to find a budget for this? Or perhaps some of the team organizers. Then you’ll need to figure out how much to charge (hint: as much as they’re willing to pay, rather than how much it costs you).
One more thing: In your post you mention that schools are cash-strapped already, but that’s not necessarily true. The budgeting system is fairly inefficient, usually “spend it or lose it and get less next semester” situation. It’d be definitely worthwhile talking to the heads of specific departments in any school that has some users (you’ll need to figure out where your users are coming from).
That’s a good point
Maybe i should personally email everyone thats signed up to my list, and ask the some questions?
“Are you using this app for speech competition or something else?
If the app was paid, who would pay, you? Your parents? Your school?"
RE: organizers. The app runs counter to the traditional mentality of filing hundreds of articles in large file cabinets. You’re right, i should reach out, but i dont have any expectations.
RE: budgets, good point. Maybe i should have a model where schools can sign up on the spot and use the app, but theu actually pay sometime later during the quarter.
Generally it’s a great idea to talk to your users/customers and get to know them better. Be careful with trusting people when they reply with things like “yes I’d pay for this!” Until you have their credit card, it’s safer to assume they lack the self awareness to make that decision in such an abstract context.
But yea, shop it around to different kinds of groups and see what you find. It’s common to be surprised when you learn the real incentives and logistics behind some of these things.
Once you get some good leads, try to close them as soon as possible. Maybe this means doing some ad-hoc deals (a placeholder page with a Stripe Checkout form?), or maybe you want to flesh out some landing pages that take pre-orders, or whatever it takes. The sooner you try to close a customer and find out they aren’t willing to put their money where their mouth is, the sooner you can color your interpretation of their feedback accordingly. Or, more optimistically, the sooner you get money in the back, the sooner you have money in the bank. :)