It's cool what you're offering, but IMO being rejected by YC isn't "adversity." Folks need to stop pinning their hopes on a handout from others. How about everyone uses their spare time to build something cool, deploy it to a cheap Web server costing $30/m, see if people use it, actually /sell/ product and then go straight to the big dog investors?
I actually think what he's offering is incredibly awesome. Startups at this level NEED a product like Mixpanel and he's offering it for free.
Not all rejection is "adversity" per se, but a lot of people had a non-negligible amount of hope resting on their YC applications. At this stage in the game everything that isn't a giant step forward can feel like a kick in the face. Kudos to Mixpanel for understanding that.
Lol no! Not "rejection" parties! Everyone is invited whether they're past, present, or future YC applicants, with or without having been accepted by YC. This is just a way for people to hang out and unwind and have fun, especially those who have gone through the application process.
Switching to anger is a practical way of dealing with disappointment - it makes it easier to move forward and take action... Your comment may help some people get over being rejected and its not like YC is affected by how people they rejected handle things.
yeah but you can write the truth without being an ass. Actually bother to make the case that YC isn't the be all and end all. Just stating it (not that you even went that far) doesn't add anything so you're being downvoted for being noise, not because you're speaking the "truth" and being oh so brave to do it on news.yc
Yep. If you're an employer, why would you advertise that you're actually looking for that 75% candidate? You'd get all the trash candidates (probably getting them anyway) and the good candidates would be like "Ew, I don't want to work for that company!" HR-types are often the ones to write those requirements, anyway, and they're just reading Internet tutorials on how to do so.
I've been there (as an employer), and because my boss often made it very difficult for me to hire when I needed to (always based on current billing instead of future billing), I had to be very particular because I knew that if I chose poorly, I wouldn't get another chance for quite a while. I interviewed many good candidates, but often opted to not hire and keep waiting for the reasons mentioned above.
Just now, I finished creating Visual Studio project templates to streamline the bootstrapping process. It's now down to just three steps! Microsoft's done a great job with the Extensions gallery. There were a couple of snags with VSIX but no big problems.
Thanks for making me aware of the AttributeRouting project; I had not heard of it before.
From quickly reading about AttributeRouting, the biggest difference between it and JuniorRoute is that AttributeRouting apparently sits on top of the ASP.NET MVC framework and Web API--both of those technologies are flawed, in my opinion. JuniorRoute does not; instead, JuniorRoute hooks directly into the ASP.net pipeline and does not reference a single ASP.NET MVC binary.
When I set out building this, I was determined to provide a solution that implemented routing in an HTTP-centric way, not the controller-centric way that ASP.NET MVC does. I think I've managed to accomplish this but I'm only one man and my opinion is, of course, biased. :)
The AttributeRouting project has it right with regards to attributes, but the project's foundation--ASP.NET MVC--is still flawed.
Some developers scoff at the use of attributes because they view attributes as magic. In my experience, attributes are a great way to implement the convention-over-configuration paradigm, but purists may choose to rely on other mechanisms for generating routes. I was sure to design the framework such that both camps--the pragmatists and the purists--could be made happy.
JuniorRoute provides built-in conventions that use endpoint namespaces, class names and method names to generate routes (this is similar to FubuMVC). The great thing is, developers can very easily extend JuniorRoute and create their own convention implementations if the built-in ones are insufficient.
Another way JuniorRoute differs from AttributeRouting is much of JuniorRoute's source code implements the HTTP 1.1 specification directly. For example, JuniorRoute's CacheableResponseHandler class handles prevalidation headers (the If-* headers). Obviously, JuniorRoute is open-source so anyone can look at the class and determine how it does that or implement their own response handler that follows the specification in a different way. ASP.NET MVC tends to hide things like that. I wanted developers to be able to choose from a stock of built-in conventions providing implementations of the most common scenarios but still have the extensibility just in case JuniorRoute doesn't cover something they need.
There are very few classes in JuniorRoute that do not implement interfaces. I designed the framework to be nearly completely extensible while still keeping bootstrapping code and configuration to a minimum. One of my biggest goals is to keep the amount of time between bootstrapping and writing endpoint methods to a minimum. I will be releasing Visual Studio project templates to make initial bootstrapping even simpler; right now, there are a lot of manual steps because one must begin with the ASP.NET Empty Web Application template.
Hi, folks, author here. I'd love to answer any questions you may have about JuniorRoute. Even though I just released it yesterday, I believe it could go pretty far to solve some of the challenges the .NET community is facing right now with regards to good Web frameworks.
The only way you will know they won't sell your data is if those terms are clearly stated in a contract between you and the vendor. Otherwise, you won't have any way to know they won't sell your data in the future.
Imagine if you are the owner of Everyday.me and Facebook comes calling, flashing a huge check. They want your data and are willing to pay big bucks for it. If there's nothing in customers' contracts stating you can't sell their data... cha-ching!
But if it's in the contract, then you know? That seems naive, you can't possibly know that they won't sell your data, but you can make an educated guess.
Yet another startup trying to use the success, brand or popularity of other companies or products to attract customers. Everyday.me, how about defining yourselves instead of "We're the Facebook of" or "an Evernote for?" Be confident about your product--that it can stand on its own and has merit above and beyond what competitors can offer.
Aside from the fact that your answer wasn't an answer, you are essentially making false claims on your Web site using words like "never" and "anything." Hopefully you don't get sued by a paying customer who holds you to account for those claims.
