Is swapping out the database layer so common you really need a complicated abstraction like the Repository model he mentioned? We've been running an app for 3 years and have never dropped ActiveRecord or Postgres.
Spinning this around on you: I worked on a project where swapping data stores around wasn't common because of tight coupling with AR. We considered swapping data stores around for different and evolving use cases and never did largely because we had so much code that we felt was tied up so tightly with AR that it would have been very expensive to swap. I think it definitely decreases flexibility, but that it's pretty hard to know if you want more flexibility ahead of time.
Pretty much all of these pattern discussions seem to be this way to me - "just do it the simple way! YAGNI!" versus "crap this one time I did need it and it was difficult to change by then! Maybe I should design things more flexibly from the start next time!". It's pretty easy to get burned going either direction, and depends a lot on things like what the project is, what organization is building it, and the level of success it ends up having. The closer a project is to a simple-CRUD, small team/unproven-company, prototype with limited success, the more sense YAGNI makes, and the further from each of those criteria a project is, the more it makes sense to design for more flexibility.
> It's pretty easy to get burned going either direction
Quite true, though I'd argue that YAGNI is still true as a probabilistic maxim. You'll make the "will I need it" decision many thousands of times in your career. If you follow YAGNI consistently[1], it will help you more often than it hurts, and you'll come out ahead in the long run.
[1] But nobody is saying you should ignore concrete evidence that you will need something later. That's its own cargo cult. If there's good reason to believe YAGNI doesn't apply in a particular case, don't follow it in that case.
I think this is a dangerous line of thinking, but I suppose I wouldn't modify it very much. What I would say is that YAGNI should perhaps be weighted higher, but that the probability of it being wrong in particular cases should be considered carefully.
With the "complicated" repository model mentioned you can transparently introduce other behavior, like a caching proxy, retry-on-fail proxy, migrate-on-write proxy, whatever. It might not be a valid use case for you, but I have seen tangible non-testing benefits of using the repository pattern.
I tend to not work on applications that work with a single data store. Some data will be stored on the file system, some in a traditional RDMS and some in a NoSql implementation. What data goes where, frequently changes and isn't really a major concern of the system, at least not the parts that need specification verification.
So you have data that one day might go into an RDMS but the next day might go into file store? Do you constantly migrate old data between the two stores? What is the use case for this? Not being snarky, I'm genuinely curious. We use more than one datastore but that data usually stays put once its committed to one format. RDMS for most of the app, Redis for quick lists and cacheing. Flat files when necessary. But those models don't change their store ever unless its a major overhaul.
It's a combination of 3 things.
1) Storing of the data is not what is central to my business case. It is an operational requirement, not what I'm selling. My major architecture requirements therefore do not get driven by what data store I'm using.
2) I frequently have data migrate from 1 format to another.
3) The actual data store formats don't change often, but each one of them has changed at least once in the last 3 years. That means that every six months we are migrating data store implementations. I don't want this to actually impact my business (see point 1) and therefore data store specifications are highly isolated from the other code.
When I worked at last.fm code that assumed all the data would always be in a single postgres database was a constant source of pain - we spent a lot of time migrating tables out of the big central database, either because the data simply didn't fit any more, or because we wanted it to be available to a Hadoop job. (There were probably other reasons, but those are the ones I remember). Maybe last.fm's an extreme case, but it does happen.
wouldn't a single abstraction over postgres, filesystem, hadoop, etc be either really leaky or really inefficient? different datastores are better suited for certain kinds of queries. It seems like the programmer should be aware of what he/she is querying.
You invert the dependency. The abstraction is over the things that the higher level code needs. I don't need to know about query types, indexes etc. I need some business answer (all log records between x/y, a user matching username x), I program to an interface that provides all the answers necessary for the high level code.
The implementation of that interface is data store aware and implements the interface in the most effective way possible for the data store holding the things I'm interested in.
Yes, if your building a user deployable product like TeamCity, Crucible, or other app where it might be deployed on a number of database tiers to fit your customer. In that case, a Repo abstraction (or ORM) makes life livable.
I echo his sentiment. Integration testing, especially when you have a JS frontend, makes much more sense. I never saw the point of controller tests and making sure a controller assigns variable @widgets with [widget] and all that nonsense. An integration test will identify all those problems and then some.
For my use case (building a reasonably complicated e-commerce platform) I find that the sweet spot tends to be integration testing to make sure the frontend is spitting out the right thing when going through the whole stack, and unit testing to make sure the correct logic is being applied when performing particular operations.
That combination allows reasonably fast unit testing, because database interaction is stubbed out for that level, which gives a decent level of confidence that nothing major has been broken within a few seconds, and then a longer 10-15 minute integration test suite which checks the stack works as a whole.
Yes, exactly. We use request specs to test regular HTTP requests to regular pages or our API. And then we use feature tests with Capybara and PhantomJS to load the app, click through it, and make it loads as it would in a customer's browser. This covers most of our application. And then we use regular unit tests for anything not customer facing, such as background jobs. But these unit tests make up only a small fraction of our test suite.
The point is to be able to unit-test business logic in the controller. If your app is just dumb crud end-to-end then sure, there's no point in anything but integration tests (and maybe not even those), but if you have any interesting logic then you can get much better coverage more efficiently in a unit test than having to run through the whole stack every time.
What are the SEO implications of this? I tried looking at their site (since they built it with their tech) and at the FAQ but couldnt find an answer. Is the content pulled via AJAX after page load? Or is it pulled server-side on the initial request?
I'm not the prismic.io developer but I believe it depends on you - how you fetch the content fragments from prismic.io. We are doing it on the backend, so it's perfectly searchable by Google ;)
See here - http://www.elastic.io/blog/82796857416/why-we-chose-api-base...
Much better memory usage and (for us at least) better concurrency. We could only run 4 unicorn workers on a single dyno. But with Puma we run 16 threads with ease.
Have you tried running 3 or even 4 puma workers (each with 8-16) threads on a dyno? That way you can get more concurrency on CPU-bound requests in addition to IO-bound concurrency (assuming MRI).
For cab service, Uber rides are serviced by already existing metro cab companies. The Uber cabs in here in Chicago were already licensed cabs, but now they can get dispatched via Uber. How is that any different from say, a cab company deciding to dispatch its drivers with their own in-house iPhone app? Do you think that would that be allowed under these regulations?
The deal Chicago has with taxi cabs is that street hails are reserved for regulated medallion taxi cabs; in exchange for that, the medallion owners are required to maintain vehicles, insurance, and coverage areas, and are required to comply with the billing procedures set up by Chicago.
Uber currently uses Chicago tax company drivers directly, but doesn't comply with the regulations the medallion owners are required to comply with --- for instance, Uber adds 20% to the fares, which is something cab companies can't do. Uber's defense for this is that using an iPhone to get a cab isn't a "street hail"; the cab companies argue that they're equivalent. We'll see who wins.
Very interesting concept! How do food & restuarant laws apply in Europe? I know here in the US, restaurants need regular inspections by the local board of health. And restaurant is defined as "a facility that prepares and sells food directly to consumers for immediate consumption."
Presumably if people are paying the host, that host is now operating a restaurant. I can already see the food lobby going crazy over this one in the US.
I think this is just another way it's "like AirBnB". I assert the vast majority of AirBnB rentals break either local laws regarding guest houses or hotels, and/or the provisions of the lease in rented accommodation.
Perhaps this service can spare itself from liability from the unlicensed action of its users by including in the ToS "you must have all valid licenses required by your jurisdiction if you choose to charge for hosting a meal".
Edit: I would imagine thing become even more complicated if guests receive wine or other alcoholic drinks as part of the meal.
Oh my goodness, you're almost certainly right about the liquor. There are oodles of laws about who can get a liquor license, as well as what they can serve, to whom, and when. I believe that you're often not allowed to have an establishment that serves liquor within x distance of a church, hospital, or school. Go tell the people at 100 Main Street that they're not allowed to serve liquor to their patrons, but that the people at 150 Main Street are.
Imagine that you're running a Cookening site in your home. Are you allowed to serve wine to the children? (I realize that this is a non-issue in many countries, but it's a very serious one in the US.) What are the penalties for giving wine to the children?
Did you see the thread in HN yesterday about the legal issues that AirBNB is having with various municipalities? That's nothing compared with what this company (and others like it) will have to deal with. I have to imagine that the health- and food-inspection departments in most states and cities are very tough. Plus, you might need to get insurance for everything from "patrons" getting sick, to kitchen fires. I don't even know if most homeowner insurance would cover the cost of damage if you were using your kitchen for commercial purposes and quantities.
And so on, and so on. As with AirBNB, I expect that we'll eventually find a middle ground between complete anarchy and stifling regulations. But on the face of it, operating a restaurant from your house sounds like a rat's nest (no pun intended) of financial and legal issues to deal with.
This might be an American-only thing, though. In Israel (where I live), many people run small catering companies (albeit not restaurants) from their home kitchens. Perhaps the government has rules about such things, but they aren't ever enforced. and in France, I can't imagine the government stopping people from cooking and serving (and selling) high-quality food.
I would think there would be a lot of trouble with this in the UK, because if you're serving food to people for money then you need hygiene certification for the folks preparing the food and hygiene assessments for the preparation areas, at the very least.
It's a nice idea, but like AirBnB it will probably fall foul of a lot of consumer protection laws, and a lot of consumer protection laws really are there for good reasons.
Getting a hygiene certificate is actually pretty straight-forward if it came to that and supper-clubs have been going fairly successfully for a couple of years now without being shut down as far as I know. I like the idea. In the uk anything that gets people from different social circles together is a great thing - I don't think it happens as much as it should. Good luck to them!
That's not really what's going on here though is it?
It's more like informal restaurant businesses, with the service acting as a directory and booking portal.
Not that I'm saying this shouldn't be allowed, but there are good reasons we have hygiene rules and it's at least worthwhile investigating how they ought to apply here.
This. I had the exact same idea (although locally oriented) about a year ago, but then I found out that all places that serve food commercially in the Netherlands require that someone on the staff is in possession of a "Social Hygiene Diploma"[1] and the health services would shut down basically anyone who attempted to do this.
I hope you guys do well, I think there's a lot of social value in this concept. Food can bring people together in special ways.
As many people have pointed out - there's a lot of potential problems and legislation that could get in the way. What constantly impresses me is that people can push right through and solve these seemingly insurmountable issues. I'm sure if AirBnB was first posted here they'd get back 50 reasons why it can't work.
"I'm sure if AirBnB was first posted here they'd get back 50 reasons why it can't work"
Absolutely this. It's a great site and a great idea. There are hundreds of reasons NOT to do something, but that doesn't always mean you shouldn't try.
Apparently just inviting people over on a regular basis is grounds for getting shut down in NYC.
"After hosting dinner parties for strangers in their own apartment, the NYC Department of Health took notice and shut them down, but Tamy and Felipe decided to open a restaurant in SOHO."
Is this anonymous copy-and-paste medium how people start to deal with their problems now? What happened to just talking to people or making tough decisions? I've seen more of these posts in the last year than I have in my entire time on HN.
I'm sorry you are having a tough time but you need to either 1) have a hard talk with your co-founders about your business model. present facts. make your case. they will listen.
or
2) if they dont, walk away and start something new. you mention you are a few years out of college. you could also go take all the technical experience you have gained over the last year and get another job. Make a decision on your own.
But really, the notion that a bunch of internet strangers will be able to give you some miracle advice is absurd.
> Is this anonymous copy-and-paste medium how people start to deal with their problems now?
Yeah, isn't it awesome? There are sure worse ways to deal with difficult personal questions.
How did we do it before the internet and crowdsourcing? Oh yeah, there was a column in the newspaper called "Dear Abby". For the entire American syndication, she handled about two questions a day.
> What happened to just talking to people or making tough decisions?
I think he has been 'talking to people' because they've written him some checks.
> the notion that a bunch of internet strangers will be able to give you some miracle advice is absurd
While not miracle advice, I cannot think of a better venue to ask startup-related questions. I don't know anyone in real life, none of my friends do this, etc. In contrast, a substantial portion (if not the majority?) of users here have been part of a startup, and have firsthand advice.
Sure, it's not miracle advice, but the fact that these are strangers on the internet is not sufficient to discount the wisdom that many here are willing to share.
I would agree, talking with the co-founders is the best route to go. Come up with good examples and/or comparisons for why you think the business model won't be a success but also propose a solution to what route you think the business should go.
Exactly. That's something you didn't mention in your story, and it is a crucial thing to do if you really believe that the product solves real problems. Don't let the unavoidable obstacles destroy your relationships. All of you are still learning (the brick&mortar business experience isn't that easy to transfer to tech startup) and that requires mistakes and dead-ends. You can treat your adventures so far as a lessons in Lean Startup fashion and check together if there's anything you all can improve.
Yes, I think after 15 months you should have a serious discussion with them. It might take a few days to agree on a plan. Make it clear you need income to go forward. They're probably thinking the same thing as you anyhow.
> Is this anonymous copy-and-paste medium how people start to deal with their problems now?
Obviously this person wanted some advice on their situation while remaining anonymous. I don't see a problem with being able to engage the community without having their name attached to it until they're ready to sit down and have a frank conversation with their co-founders.
> But really, the notion that a bunch of internet strangers will be able to give you some miracle advice is absurd.
I'm not sure how asking for advice is expecting "miracle" advice. There is a difference between the two.
I don't think it is entire absurd that internet strangers can give good advice. That said, it is entirely impossible when given no actual information or goals, just a scrawling whine.
the second image uses the word "exile" several times. Exile is typically associated with being cast out from one's group. The _why saga was before my time as a Rubyist but I always thought he vanished, i.e. left on his own accord.
Was there an "exile" event that I am not aware of? Or does anyone know what he's talking about?
I can't think of any specific "exile event", but it did seem some time before he left that there was a trend in the Ruby/Rails community that made him feel unwelcome. That trend was "replace why's libraries and make noise about how his library wasn't any good".
Hpricot in particular was under heavy assault. I'll be the first to say that maybe it wasn't always the most performant solution, but for a long time it was the only good solution (and I tried a few). So when people are ripping your libraries left and right, forgetting to pay a little bit of respect to how big an impact he had on the community, then yeah...I could see how he'd feel the need for a self-imposed exile.
While I've never followed either of the stories that closely, isn't that fairly similar to what happened with Zed Shaw? Only in Zed's case he ended up finding a happy home in the Python community vs. completely disappearing from the face of the earth forever.
Zed (his real name? Seems like one) became famous by putting on a loud obnoxious persona, plus complaining that people used his work (mongrel) without appreciating him.
Why (not his real name!) became famous for his work's weirdness. And his "enemies" disliked how capricious and weird his work was, not the sort of thing to build a Real Serious Business on. and he fled from the public eye into self-imposed exile when people started piercing his intentional veil of anonymity.
I always thought that sucked. Its easy to take something that exists and make it better. Its damn hard to decide that something should exist in the first place and give it a try.
Like X only betterer is the ghetto of the technically talented but uncreative.
He also claims (in the footnote) that Jack Black is another "character" he plays (making fun of their similarity in appearance). I'd take all of it as somewhat tongue-in-cheek
Some people are still understandably mad at him for taking down his repos when he disappeared. He probably feels a bit like a pariah, even though his actions were of his own choice.
There is a long history of the phrase "self-imposed exile". It's even the example for the word self-imposed in the American Heritage Dictionary
There are a lot of different ways to be exiled. From what I gather, his privacy was violated so he left. Whether his privacy was violated out of excessive fanboi zeal or as an expression of lack of trust/attempt to verify something or some other reason, it was a form of hostile event which drove him off. He was not being accepted on the terms he wished to set, in essence.
He did delete his own accounts, yes, but that doesn't mean that he didn't _feel_ unwelcome.
Also, if you take _why as being separate from the human being who played him ("Subject" is the best I've got), Subject could have imposed exile upon _why, because they're not the same person. http://words.steveklabnik.com/why-is-a-role-not-a-person
I'm not going to link to anything for reasons which will be obvious, but basically, _why asked for privacy and someone doxed (outed) him. At this time, _why decided to vanish. I don't know that _why ever said why he vanished (he vanished, after all), but most assume that he left because he was doxed. This made Hacker News at the time and a follow up article about _why I read a couple of years later appeared to verify his identity.
You can also specify a meta robots tag inside the page HTML. If you want to block a lot of pages, your best bet would be to add it to your master layout or template. You get the same effect of blocking on robots.txt but without exposing a list of blocked pages.
The downside is that Google will still crawl the page and use your bandwidth, but the page won't be indexed.
