visualcsharp

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?

Is this serious? Folks really throw rejection parties?

Uh oh, downvoted for writing the truth? That's /never/ been done before--not /once/!

OH NOOOOOOOOOOOOES!!!!11eleventyhundredandone!!

Life goes on, folks, in spite of angel investors wanting every last ounce of your collective creative juices for almost no wage.

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.

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.

The updated quick-start can be viewed at http://projects.nathanalden.com/JuniorRoute/documentation/1.....

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 point is, a user has recourse in that event. Without those contract terms, they don't.

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!

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.

Then why not just say you list things chronologically? Why confuse your potential customers by making them work backward from Facebook's Timeline feature to simply listing things chronologically? If you have to attach to Facebook's success in order to sell your product, you probably have a long way to go. Try defining it in your own words.

Bingo. That's one sentence that sums up the vast majority of tech startups nowadays.

Most of their Web site seems to consist of jargon and puffery--"across the enterprise," "enables" and "ecosystems."