Featuring NuGet on The Daily WTF?

[Alex Papadimoulis]

Hi Guys,

I've been pretty frustrated with developing for/on NuGet over the past few years, and this v3 API really takes the cake. So, I'd love to turn my frustrations into a fun TDWTF article.

Of course, most articles are anonymized, but there have been plenty of "public" ones; http://thedailywtf.com/Articles/Sketchy-Skecherscom.aspx comes to mind. They've all been one-way, but I'd really like to have an article that actually interviews project members to get their insight. This would be an opportunity to explain something a "regular dev" like myself just might not understand, defend terrible technical decisions (*cough*JSONLD*cough*), or even blame your predecessors. 

The main theme would be to make light of some technical disagreements, and cement a point I've made for years: good software does not need good code.

Would you guys be interested and able to doing this interview? It wouldn't take much time; we would do it over voip and send the questions ahead of time.

Cheers,

Alex

[Jeff Handley]

Alex,

 

I appreciate that you’ve begun reviewing our API v3 work.  As I’m sure you’ve read from our NuGet.org Architecture post, we’re having to make significant changes to our architecture to ensure long-term scalability of the service as it’s being depended upon by more and more developers.  I also appreciate that you contribute to the NuGet ecosystem by providing both the free and commercial offerings of ProGet.  You are one of a handful of companies who have a business investing in the NuGet ecosystem itself, not just producing packages; we recognize and value that.

 

Our team’s primary goal is to ensure a reliable end-to-end experience using NuGet within Visual Studio and connecting to nuget.org.  Other package sources are always in our minds, but ensuring that nuget.org itself can stand up to the traffic it gets (and will get) is the highest priority for us.  Once we came to the conclusion that a fully RESTful API would accomplish our scale requirements and with JSON being our format of choice, we researched existing and custom options and found that JSON-LD was able to provide all of the features we were seeking and much more.  The fact that it’s becoming a W3C standard helped validate our decision.

 

While we are not at all interested in the TDWTF article you’ve suggested (and to be honest, the proposition was rather insulting), several of us on the team were intrigued by your reaction to our selection of JSON-LD.  We are open-minded and we’re curious what is driving your reaction.  What experience do you have with JSON-LD that lead you to conclude that it’s a “terrible technical decision?”  Is there another approach that you’d suggest in place of JSON-LD?  Is it the Linked Data part of JSON-LD that you don’t like or is it the JSON part?  Is it just the JSON-LD detail that you disagree with or is it the premise of the CQRS pattern and deprecating the use of OData in the process?  Are you worried that some of your ProGet scenarios are going to be adversely affected?

 

Is your reaction based solely on our current “intercept.json” that we have in place for intercepting v2 OData API requests on the client and transforming them into JSON-LD requests?  If so, please know that the interception approach is merely a stop-gap implementation—one that allows us to get the architectural benefits of the CQRS pattern before we’re able to completely rewrite the NuGet client to truly understand the new API.  The only API we’re exposing thus far is for serving this interception, but it does expose some of our design principles that we will continue to follow as the API evolves.

 

You’ve never really engaged with us on how ProGet integrates with NuGet or NuGet.org (other than to angrily report issues we’ve caused for you that were outside our test matrix).  And it seems the only times we see you engage with the NuGet ecosystem is when you are bashing us for one reason or another (with this post being another example of that).  As I said, we value companies that invest in the NuGet ecosystem and we’re open-minded.  So if you’d like to provide some constructive feedback and/or help us make the NuGet project better for everyone (including NuGet-based software vendors), we’re happy to listen and collaborate in an effective way.  I specifically reached out to get your attention to come read about our v3 work because we do want you engaged—your responding by just insulting us and not providing any useful feedback doesn’t benefit anyone.

 

Jeff Handley

--
You received this message because you are subscribed to the Google Groups "NuGet Ecosystem" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuget-ecosyst...@googlegroups.com.
To post to this group, send email to nuget-e...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Papadimoulis]

Hi Jeff;

Sorry; my intent was not to insult... though, re-reading my post, I was it was quote insulting. Probably had one to many scotches. Still, I'm sorry... and to be clear, I do feel that your team has accomplished it's primary goal: ensure a reliable end-to-end experience using NuGet within Visual Studio and connecting to nuget.org.

But I still think there have been a lot of technical decisions made since day 1 (NuPACK days) that many (including myself) would consider major WTFs; when I saw you opted for JSON-LD in v3, you can guess which three-letter acronym I said aloud. Obviously you guys didn't draw it out of the buzzword hat, so I think it'd be quite interesting to understand why opted for a "technology" that, so far as I can tell, takes the worst parts of XML and amalgamates it with the worst parts of JSON.

I've spent about an hour reading about JSON-LD, and I could probably spend a couple paragraphs ranting and whining about why JSON-LD should actually be JSON-WTF; but that's what I had in mind for the article. It might be valid criticisms, but my goal would be an entertaining technical discourse. But this is where I thought weaving your feedback/interview/comments in would be great; in the Sketchers article I linked, the author came on and made some amazing insights. I would have *loved* to interview him before the article, and have those comments in the article itself.

This, btw, was what I meant by "making light of technical disagreements". I get criticized ALL THE TIME for developing not just on .NET, but on Windows, but my response is usually something snarky like, "I prefer real platforms and real operating systems, instead of linux ruby toys."

Ultimately though, what the core thrust of the article would be is that, despite all this (seemingly) WTF code/tech, the software still works fine; more than fine in fact. Is it really worth coming up with technical "perfection" if the actual organizational/team goal is "ensure a good experience"? Do these even matter if the goal exceeded?

So, to be clear, it would not be a "NuGet is feces" article. I mean, I may be an asshole, but I'm not thaaat big of an asshole, and even if I believed it, I wouldn't lambaste something like that. I was thinking more an article like, "I've worked with NuGet for years, I think it has a lot of WTFs, here's what actual devs had to say, and doesn't really matter b/c platform works great."

I hope you guys reconsider; I think this would be fun, and show NuGet in a great light, despite of me poking fun at some tech choices.

Also, I know I come across like an asshole in the forums/bug posts, and that's usually because I'm frustrated at the time about downhill bug/issue/whatever. Regardless, I'll try to be more constructive.

Alex

[Jeff Handley]

Alex,

 

Thanks for clarifying your intentions.  I’m still going to decline the proposal though.  We will continue to use our blog and this ecosystem forum for discussion on the matter.

 

Best regards,

Jeff Handley