5 ms·

The majority of Loopt's back-end runs in Windows Server 2003/2008, .Net 3.5 and SQL Server 2008. We have some Ubuntu, PostgreSQL, MySQL, Ruby, etc. as well. I

by kogir 17y ago

The majority of Loopt's back-end runs in Windows Server 2003/2008, .Net 3.5 and SQL Server 2008. We have some Ubuntu, PostgreSQL, MySQL, Ruby, etc. as well. I really enjoy the tooling, the documentation, and the libraries. There is exactly one time we've run into an issue with the built in libraries: The documentation didn't match what really happened, but Microsoft confirmed this for free and fixed the docs. Visual Studio is rather polarizing. I'd say the developers at Loopt fall into three camps: Like it, miss Eclipse, and still use Emacs. You don't have to use it. I can't type more than 20 WPM; Intellisense is so good I haven't felt the need to learn to type properly. Cost wise it's really not a problem. There's BizSpark which is great for three years, but after that you can get into their SPLA licensing program. It lets you pay per month for only what you use. See http://www.microsoft.com/serviceproviders/licensing/default.mspx http://www.microsoft.com/serviceproviders/licensing/default.... Loopt started before BizSpark, so we know what it costs. Here's a hint: we paid more per month for Office and Exchange than we did for the software running our service. All in it was less than hiring an intern. If you're super strapped for cash, just get an MSDN subscription, and use it for everything. It's not legal, but Microsoft knows there's more money to be made by letting you become successful (at which point you pay real money for licensing) than there is in going after your initial few counts of infringement. If you like getting into the guts of things you might not like .Net, even though they've released many of the symbols and source code. See http://msdn.microsoft.com/en-us/library/b8ttk8zy(lightweight).aspx http://msdn.microsoft.com/en-us/library/b8ttk8zy(lightweight... That said, you can't edit it. I'm ok with this though because in my experience it just works. I'd rather focus on developing my product than fixing the tools and runtime I'm using. The open source .Net scene is a little touch and go. There are some great projects out there, many by Microsoft itself, but it's simply not as robust and vibrant as the Linux open source community. This seems to be changing (slowly), but as I said earlier we've found compelling reasons to have a mixed environment. I'm not saying it's all good. ASP.Net is a valiant attempt to solve the wrong problem. Drag and Drop doesn't work for the web. .Net MVC is much better. Despite that, our website is written in Rails, and communicates with our back-end using Thrift. It works great. If you want to know more let me know. Maybe I'll write a blog post. Edit: Grammar

tentonova 17y ago
Unless the tools/languages are tremendously better than what is available for free/cheaper, I don't particularly understand the value in: - Risking Microsoft's ire by breaking the licenses - Locking yourself in to long-term Microsoft licensing This was a pattern I saw in many, many startups in the 90s -- organizations that relied first on UNIX systems for their servers (often times Solaris, Linux, and in the early-to-mid 90s, IRIX), would eventually adopt Microsoft products for some component of their infrastructure -- usually Exchange, based on heavy political pushes from the growing number of business users. This always to the same effect -- the Microsoft products spread due to lock-in network effects until it began to near 100% MS on the desktop, e-mail, and corporate servers. Production servers generally remained UNIX due to the costs involved. The IT organization shifted to MS, costs went up as the staffing necessarily increased to support administering Windows systems, expensive political maneuvering arose between engineering and business as they both fought to move to systems that they thought better aligned with business priorities. At the end of the day, everyone wound up locked to MS with heavily entrenched political interests in keeping the status quo (and the job security that went with it). Having seen the fall-out from migrations to MS products in corporate IT, I can't imagine voluntarily implementing MS as the primary production and developer system at a startup. You're locking yourself out of alternative solutions, you're signing up for significantly increased capital and operational expenditures, and perhaps most importantly, you're excluding an entire class of software engineers that primarily work on UNIX-based (including Mac OS X and Linux) systems.
- MrFoof 17y ago
  >Unless the tools/languages are tremendously better than what is available for free/cheaper, I don't particularly understand the value in... There's tremendous value if it's what you already know. The opportunity cost associated with learning and becoming reasonably competent in a different development stack can be non-trivial, especially if you had 5 to 10 years of experience with a different stack or set of technologies. I've yet to encounter a new framework/API/stack/language which I've been able to move to in only a few weeks and be 80%+ as productive as what I already knew, as there's often lots of useful minutiae, subtleties and new concepts you need to acclimatize over time. >You're excluding an entire class of software engineers that primarily work on UNIX-based (including Mac OS X and Linux) systems. The converse also applies. Granted, a competent engineer can learn anything, however you're initially inclined to pass on them because of the associated ramp-up time.

by kogir 17y ago

tentonova 17y ago

Unless the tools/languages are tremendously better than what is available for free/cheaper, I don't particularly understand the value in: - Risking Microsoft's ire by breaking the licenses - Locking yourself in to long-term Microsoft licensing This was a pattern I saw in many, many startups in the 90s -- organizations that relied first on UNIX systems for their servers (often times Solaris, Linux, and in the early-to-mid 90s, IRIX), would eventually adopt Microsoft products for some component of their infrastructure -- usually Exchange, based on heavy political pushes from the growing number of business users. This always to the same effect -- the Microsoft products spread due to lock-in network effects until it began to near 100% MS on the desktop, e-mail, and corporate servers. Production servers generally remained UNIX due to the costs involved. The IT organization shifted to MS, costs went up as the staffing necessarily increased to support administering Windows systems, expensive political maneuvering arose between engineering and business as they both fought to move to systems that they thought better aligned with business priorities. At the end of the day, everyone wound up locked to MS with heavily entrenched political interests in keeping the status quo (and the job security that went with it). Having seen the fall-out from migrations to MS products in corporate IT, I can't imagine voluntarily implementing MS as the primary production and developer system at a startup. You're locking yourself out of alternative solutions, you're signing up for significantly increased capital and operational expenditures, and perhaps most importantly, you're excluding an entire class of software engineers that primarily work on UNIX-based (including Mac OS X and Linux) systems.

MrFoof 17y ago
>Unless the tools/languages are tremendously better than what is available for free/cheaper, I don't particularly understand the value in... There's tremendous value if it's what you already know. The opportunity cost associated with learning and becoming reasonably competent in a different development stack can be non-trivial, especially if you had 5 to 10 years of experience with a different stack or set of technologies. I've yet to encounter a new framework/API/stack/language which I've been able to move to in only a few weeks and be 80%+ as productive as what I already knew, as there's often lots of useful minutiae, subtleties and new concepts you need to acclimatize over time. >You're excluding an entire class of software engineers that primarily work on UNIX-based (including Mac OS X and Linux) systems. The converse also applies. Granted, a competent engineer can learn anything, however you're initially inclined to pass on them because of the associated ramp-up time.