robconery

If the alternative is "rubbing you the right way"... I'll pass :). If you had the time to be a bit more concrete with your thoughts - it would probably help. I'm not an audio engineer, I'm a developer like you.

A very convincing argument.

It's an HTTP git receiver - nothing magical there

If you don't mind - let's shift the context :). If you didn't have to use a Build Server to deploy with (in other words you had a competent tool that could deploy, run tasks, etc) - I would assume you'd use that tool.

I do understand it's what you (and me and others need to use) - but it's because there really isn't another choice.

Thus my post.

I think we'll differ here - but it's a nuance really. In .NET your BuildServer has everything to do with deployment by necessity - that's not the case in other frameworks.

It does work, it is convenient, but that's not a Build Server's function in concept.

Which things RE deployment did I leave out? I was considering the config as part of the coding...

If you're one person working alone - then yes a "button push" might work for you. For teams of many people that like to push "panic patches" - that doesn't work out so well.

I don't see how this is "straightforward". You have to have a server that runs TeamCity - which means installing TeamCity and setting up a build config/environment. This is all well and good for most teams - it's needed to keep the team from checking in crap.

But you're using that setup to deploy your code - this is the missing piece to me. Why would you push from your Build Server? It has nothing to do with deployment (in concept).

Moreover you say that "Rollbacks are trivial" - which is hardly the reality for most people. How do you rollback a push from your BuildServer? Manually?

How do you alter your DB Schema? What if your deploy screws up your DB Schema? I guess what I'm asking for is a bit more detail here - you're sort of waving off everything I posted about (and experienced over the last 12 years)...

You would be wrong about that. Consider that with MVC you don't have the entire, massive Page Lifecycle thing and a control tree to parse and walk through (decrypting ViewState, assigning control values, and so on). MVC is actually faster than ASP.NET WebForms.

But it's faster in pico seconds (meaning it's immeasurably faster) and if you're worried on that level - you're doin it wrong :).

It does, yes. I don't know if that's a purposeful design consideration or what - but in general that kind of thing in your view is a bad idea. Put it in a helper or drop it in your model.

Thanks for that - yep forgot the link!

That page lists a number of startups - sure. It's atomic compared to the startups out there. I do agree - it's impressive to see some of the names on the list and it would be nice to see it grow. All the same, you have to admit that it's rather small.

I don't mind having a discussion about this stuff, but calling me a liar is a bit out of bounds.

Now - here's the thing: I've said the same thing 5 times, and you refuse to see it - which is that the software isn't free. The dev tools are covered under MSDN - so yes I'll give you that. And you can engineer it so that your dev team stays very small and you don't need to purchase additional slots.

But that's where it stops. If you run the MS stack with VS, you'll need IIS, SQL Server, and all the other bits that go with it. These are the money-making SKUs friend - and that's my point.

They. Aren't. Free.

So which is it? Devtools? Or can I build $50B Google for free, as you said above.

Double talk indeed.

That's great that it works for you - and I don't think anyone is suggesting it's a bait and switch (I tried to be very careful with the post's wording). My point in this thread isn't that it's duplicitous - more that it's not free.

I'm sure you guys had to work some licensing (which probably came under an agreement to enroll in another program). This isn't free - it's an engagement. If you left the program you would have to pay, I'm sure.

And if it works for you - that's good stuff. I'd be very interested in reading about your choices and why you went this route.

It's not free - the thing you're not seeing here is that if you don't qualify for the continued "free-ness" of BizSpark (meaning re-upping), then you need to buy an MSDN license and make sure that your dev staff is covered appropriately with those licenses.

You CANNOT run production SQL on an MSDN license - neither can you run a web server on an MSDN licensed version of Windows Server. Well, you literally can but you'd be in violation.

It's not FREE. Microsoft doesn't make software to give it out to anyone claiming they're a startup. Read the entire FAQ in its entirety, then understand the licensing for web servers and web data servers - you'll quickly see that you'll need to enroll in other programs (ISV or otherwise) to get the discounts.

Have a read here (I think this is what you're referring to): http://www.bizspark.com/Programs/Pages/GraduationOffer.aspx

Note that if you keep your MSDN license, it doesn't entitle you to use much in production. You can't, for instance, run SQL Server in production using an MSDN license. Nor can you use Exchange and Windows Server.

So it's not free :).

I think you might need to go back and read the terms again :). You're given 3 years (for a $100 fee) of what amounts to an MSDN license (which is pretty restrictive) and then you need to pay. If you want to keep the MSDN-type thing (re-upping) you can - but if you've grown, you can't.

Which means you have to pop for licenses for VS, Exhange, Sharepoint, Office, SQL, Windows Server, etc. SQL and Windows Server is the big one... especially if you've built Google.

But it's not free if it's only 3 years - you still have to pay don't you? I'm not arguing the utility of it - I'm wondering if you would have paid anyway - or if the 3 year "loan" made a difference.

This is interesting - I'm assuming that by "Exchange Integration" you're talking about Calendaring, appointments, and so on yes? I don't get the connection between your use of Exchange and your client's use of Exchange.

Put another way - I'm imagining you have a "Add to Outlook" bit of functionality which makes perfect sense. But the format is quite open and it, after all, a text file. How does this jibe with your web offering and your need for Exchange?

The main reason I ask is that Exchange is (generally) seen as not necessary in a startup (company < 20 or so). Typically they'll use Google apps or another hosted service which will accept their domain (Live.com does this as well).

Can you detail more why you needed Exchange with a Web app?

No - it doesn't replace all of it. Just the parts that I need. As I mention Squeeze is a fine tool but I don't need integration with Sorenson's hosting platform, and you can pretty much write whatever workflow you need in Ruby.

So I take it back - I do think this replaces Sorenson pretty handily :)

As I mention in the article, for Zencoder to work it has to upload your file. We encode from a single master which is usually well over a gig (uncompressed, fast render from our editor).

It takes a few hours to get that single file up to anywhere online. Rather than do that, I'd rather push the smaller files individually and pay nothing for it.

Make sense? And the $600 of software is Sorenson Squeeze.

It's a fair point - the problem is that if I'm going to ask for a user/password for a master account then... WTF do I need OpenID for?

Also - in terms of reading the spec - we use JanRain/RPX so I let them worry about that.

The problem is less that it's easy to forget - it's more that it's easier to completely lose someone. For instance, you forget your login to HN and you can go through a reminder process - pretty simple. You forget your Open ID you're in a world of pain.

Moreover most sites can't help you - the URLs contain (usually) no information about you as a person. So you come to me and say "I don't know my login" or worse: "My Open ID provider is gone".

All I can do is shrug. The it becomes a matter of sleuthing: IP addresses, PayPal transactions (if you use them)... and so on.

I agree it can be better - but it's technology that when mixed with users is a nightmare.

Here's our story from starting out with .NET and then moving to Rails: http://www.infoq.com/articles/architecting-tekpub

There are technical reasons and financial reasons for choosing either one. Have a read - hope it helps.

The link is here: http://webcache.googleusercontent.com/search?q=cache:kpzaEp0...

That's not entirely accurate. MVC releases major releases once per year - Rails releases quite often... just not full point releases. In fact they pushed 2.3.4 and within a week pushed 2.3.5 as there was a bug found :).

Yes, you can use any DB - good point.

Well - it's Andrew's thing... I just helped out as I could. Just ran out of time :)

Unfortunately no matter how many times I write that "you can do this in [LANGUAGE]" - people don't see that part :). It's no the doing of it - it's the doing of it well. Cleanly and expressively - that's what I like about Ruby.

You have to see in the code you write here...

The "Tinker toy" reference was with respect to anonymouse delegates:

var thing () => {//code}

I think Anders is going to run out of symbols soon :).

The code you write here is fine - but you're tying Artist to the ParseKey method - which is the point of doing the block in the first place (to free that up). This might not look obtuse to you - but it's a lot more code than I have :).

Also - please don't forget the tie-in with method_missing; the reason it's nice is you're freeing your calling code from understanding the parser - which I don't think you can do here...

I could be completely wrong - I do like the "or" syntax as well - reads much better.

Brilliant! Except at the end...

end.should be "Ruby"