We (msgooroo.com) use the .Net stack on Azure and have found it to be quite good. We have even been experimenting with the new vNext / OWIN stack which appears even better and will give us the flexibility to run on Linux.
Azure is a bit hit and miss. Its brilliant for getting something up an running quickly (using websites / SQL Server), but is a little flaky at scale.
Key problems include connection issues with SQL Server, connection issues with their hosted Redis service, pricing of SQL Server when using advanced features like geo-replication.
All in all though, its a pretty good development experience once you get your head around the fact that in the cloud services fail and there is nothing you can do about it except plan for it.
Oh and the Bizspark program they have gives you $100 worth of free hosting on Azure which is always nice.
> Key problems include connection issues with SQL Server,
What sort? If it's intermediate connection problems .NET 4.5.1 added Connection Resiliency to ADO.NET [1]. If you're using a recent enough version of Entity Framework it goes even further [2].
public class MyConfiguration : DbConfiguration
{
public MyConfiguration()
{
SetExecutionStrategy(
"System.Data.SqlClient",
() => new SqlAzureExecutionStrategy(1, TimeSpan.FromSeconds(30)));
}
}
The above SqlAzureExecutionStrategy will retry instantly the first time a transient failure occurs, but will delay longer between each retry until either the max retry limit is exceeded or the total time hits the max delay. The execution strategies will only retry a limited number of exceptions that are usually tansient, you will still need to handle other errors as well as catching the RetryLimitExceeded exception for the case where an error is not transient or takes too long to resolve itself.
Yeah, we use .Net 4.5.3, without EF. Connections still fail all the time especially under high demand.
We have our own retry logic, which also logs the issue so we are aware of how frequently errors occur while a command / transaction is being executed.
This is using SQL Azure with the "Business" tier, so it will be interesting to see how the new (much more highly priced tiers) Standard and Premium tiers go.
Might be worth checking out bizspark [2], as I know it lists lots of startups that are using a .net stack.
Also probably worth mentioning what you're compiling the list for if you want more responses from HN users...
More info: We actually don't host on Azure (Web Sites not flexible enough for us), but use a mixture of AppHarbor [3] (awesome product and team), and various Amazon web services.
The issues were all "Web Sites" specific. I'm sure we could spin up machines and get everything to run - but that's much less enticing compared to AppHarbor / Beanstalk.
One example - if you have any processing in the application_startup, Web Sites won't work for you. Applications are randomly killed and restarted, and don't allow for a startup time, meaning outages when this happens. Customer support suggested using a fail over to work around this, but the fail over only kicks in once your app has been down for a certain amount of time - so you'll still have down time.
What if your running app relies on the processing done during startup?
Sure - we could re-architecture the app so that isn't a requirement, but then I'm making design decisions based on Azure constraints. Why would I when there are alternatives like AppHarbor?
Planning to launch a SaaS product full .NET stack running on Azure, BizSpark gives you almost a year of free server time ($3700 worth, 9 months worth of their biggest single VM uptime).
It's hard to say no when they give you so much free stuff for a startup-style business.
It's actually pretty easy once you realize that you have to pay for the licences on all Microsoft technologies once BizSpark ends. It gives just enough time to be too locked in to easily adopt a different technology stack.
I'm using ASP MVC 5 with Knockout.js, hosted in Azure, for my startup (commuting.io, still in dev). I've come from a .net background, so it seemed like the easiest choice to get up and running.
Also using SQL Azure and Redis for data storage/caching - it's been mostly positive so far. The downside with Azure has been the portal/management experience. The current UI is somewhat sluggish and disorganized, and the new portal tile UI is extremely confusing to navigate.
Overall it's been a pretty pleasant experience (maybe minus dealing with web.config files).
the new portal tile UI is extremely confusing to navigate.
Seriously. I don't know what they were thinking. I don't mind the current portal. It does take seem sluggish with all the ajax/loading but at least I know where everything is. The new portal needs to be completely redone.
Using a cluster of Owin (self-hosted) servers with NancyFx on Mono to host REST APIs behind nginx for a distributed-computing solution on AWS. Also use EntityFramework on Npgsql+postgres - experience has been positive.
Only downside is that for something like a customer-facing portal, the identity-management is tied to Windows-specific features, for now - so have had to build a custom solution for this that runs on Linux. Waiting for ASP .NET vNext and its Identity solution when it becomes slightly more mature.
EDIT: Also evaluating a move to Azure. Primary driver (for choosing the .net stack) has been prior experience with C#, .NET and Visual Studio
Octopus Deploy [1], which is automated deployment software primarily for deploying .NET applications is written in .NET. For those that have commented about using Azure in their start-ups, you can use Octopus Deploy for that also.
We are using .Net MVC with C#/Typescript at Makemake.io (still in dev) on Azure. The biggest benefit for our project is Visual Studio and Resharper's Typescript support - it's really helpful for writing big Typescript apps (right now we have 400+ Typescript files in our SPA).
Bizspark is also great! $150 per month of free credit really helps - especially at the early stages.
We are using Windows, the .NET Framework, IIS,
ASP.NET, and Visual Basic .NET. We're on
the .NET Framework 4.0 and see no reason to
move to 4.5.
For C#, not interested: The syntax borrows from the
deliberately idiosyncratic syntax of C, and
the Visual Basic syntax is more verbose,
easier to learn, teach, and read, and, thus,
less error prone, is as a programming language
in its semantics, features, and functionality
essentially equivalent to C#, that is,
the difference is mostly just syntactic sugar,
and apparently is about as
good as C# or anything else at getting at
the CLR and the .NET Framework.
For F#,
people back to Backus have been working on
functional programming, and, for
more than just curiosity, and certainly
for the work of our start-up, we're not
impressed or interested, in that or
logic programming, rule-based programming,
or standing on our heads in the corner
programming, etc. -- sorry 'bout that;
we can agree to disagree, and YMMV.
We're quite pleased with Visual Basic
.NET. A hat tip to the Microsoft
Visual Basic group.
Main gripe: For
the documentation, actually for all the
documentation on MSDN, especially for
SQL Server, please, please,
please, get a least a C in
technical writing 101. Our biggest problem
in our start-up, far and away, much, much,
much more difficult than everything else
combined, literally, is the low quality of
the technical writing at MSDN.
For JavaScript, Microsoft's ASP.NET writes
some for us, but so far we have yet to write
a single line of it and will delay doing
so as long as we can, hopefully forever.
For ASP.NET, we are using just the basics,
that is, with
Sub Page_Init
Sub Page_Load
Sub Page_PreRender
Sub Page_Unload
etc. We have heard of MVC, looked at it
a little, can see no reason for it
or advantage in it, and
intend to have nothing to do with it.
Maybe better technical writing at MSDN
would let us take MVC more seriously.
We type into our favorite text editor and
make no use of an IDE nor do we want to.
For developing code for Web pages,
ASP.NET and Visual Basic work nicely together
-- it works fine. Actually, it's nice.
For a session state store, we wrote our
own using just instances of one class,
de/serialization, TCP/IP raw sockets,
and two collection classes. On an 8
core processor at 4.0 GHz, our session
state store should be good for 11,000+
transactions a second; transactions
is appropriate because the code is
single threaded. Yes, on an 8 core
processor we would run several
instances with sharding.
As we go live, our server will be just
a single full tower case with an 8
core processor, 32 GB of main memory,
some SSDs for a special purpose
particular to our start-up,
and some disks, with Windows
Server, SQL Server, IIS, ASP.NET, our
Web pages, our session state store,
and some specialized back-end servers.
The software and architecture are
scalable via just simple sharding.
We have little or no intention of using
the cloud soon or ever.
As we go live and grow,
after the issue of the MSDN documentation,
no doubt, and closely related to the
documentation issue, our biggest concern
will be Windows Server, SQL Server, and IIS
installation, configuration, updates,
security, monitoring, management,
performance, administration, reliability,
backup, and recovery -- little things like
those. But from some of the just astounding
successes Microsoft has running server
farms with their software, clearly
terrific results are possible; maybe we
will be calling for some high end technical
support.
Trolling? Not at all. Instead, it's just
what we are actually doing.
I'll let them all know that they have a
choice: (1) Make money doing the work to
make our software and Web site good,
our users happy, and our start-up successful
or (2) grow their resumes for jobs
elsewhere.
With (1), they get to help build something
important. With (2) they get to add buzz
words of questionable utility for unknown
projects of questionable value. YMMV.
But if your kitty cat, puppy dog, or baby
walks across your keyboard, or if something
falls on your keyboard, etc., and suddently
Firefox closes after 10 seconds, and keeps
doing that,
as you keep restarting Firefox,
no matter what,
you may
very well like my post and its solution.
Or, you can do a Google search and find that
the symptoms are common, and find that the
recommended solutions range from reinstall
your anti-virus software, install a new
version of Firefox, reinstall device drivers,
..., buy a new keyboard, give up your kids,
divorce your spouse, buy a new computer,
submit to full castration,
move to the woods in northern Canada, or worse.
Instead, just use the solution I found.
Piece of cake.
It's easy to suspect that my simple discovery
will solve a major fraction of all the
instances of that nasty, fairly common
problem, hilarious or not.
Exercise: Before reading my solution, guess
what it is! Record your guesses here before
reading my solution.
Hilarious? Maybe. Obvious? No. Useful?
Yes. Difficult? No. Fast? Yes. Easy?
Definitely. Better than the suggested
alternatives? By some light years.
You joke, but this stuff happens. I'm not a startup, but I'm working on a native app for Windows. The client comes in at ~60 KLOC, all in Visual Basic.NET. The WCF service is around 12 KLOC, and will probably grow by another 5. No third-party libraries at all (no Entity Framework either), no LINQ (no good for perf-sensitive code paths, there's just too much plumbing), and no WPF (it's all Windows Forms).
What I wrote is literally true, but maybe
there is some humor in there somewhere.
For WCF, LINQ, and WPF, we looked at the
documentation, and it was clear that just
working through the tough parts of the documentation
alone would be much more work than just writing
our code directly. Moreover, any bugs,
security problems, need for updates, etc. of
WCF, LINQ, and WPF we just neatly avoided.
And we saved maybe a lot of address space.
That is, it looked to us like, for us, YMMV,
WCF, LINQ, and WPF are a candle not worth
the match. I can believe that in some
situations those three could have some value;
for us, I don't see the value.
I mean, WCF boils down to TCP/IP raw sockets,
right? Well, the API to raw sockets is
about the easiest I/O one could hope for,
nearly as easy as the ancient Basic statement
PRINT or the same in C, etc. I tried for
several days to make sense out of WCF,
came up with zip, zilch, zero, nichts,
nil, nada, and gave up,
but I learned raw sockets in about three
hours one afternoon decades ago. To heck
with WCF.
For LINQ, that boils down to just SQL, right?
Well, SQL was supposed to be really easy to
use, is profusely documented, and has been,
for decades, has long been an ANSI
standard, has been tested in various ways,
and with astounding severity, around the world,
for decades, right? So, writing some SQL
is not so tough. Getting a connection
string to SQL Server? Yup, that took two
weeks of mud wrestling, but the SQL statements
were easy enough to write. SQL's fine.
Very glad to have it. SQL Server connection
string mud wrestling? Did I mention some
bad documentation? The full power of the
Microsoft Corporation still is unable
to document how to write SQL Server
connection strings. The only way I
learned was via Google searches wherever,
and then I did some organized trials
of essentially all possible combinations
of everything involved until it appeared
to work. I still don't know just why
what worked did and what didn't work
didn't. Cave men with burnt sticks
wrote better documentation on cave
walls.
For our SQL Server database schema,
that is, the specifications of
the tables, the columns, etc.,
we have a little file, just awash in
comments, nicely clear and easy to read,
that we run through
the wonderful SQLCMD.EXE -- "Look,
Ma, no GUIs!". And no clicking!
Instead, just type the name of a little
script, and presto, boom, have
a new database created just as
want, nearly no chance of anything
going wrong. It's better than most sex!
For the SQL Server Management Studio, can use
it read only a little and otherwise just
can't make sense out of most of the screens,
windows, sub-windows, check boxes, terminology,
concepts, etc.
So, for SQL Server administration,
just back to the simplest
little SQL statements, mostly industry standard.
The SQL Server documentation of users, logins,
etc. wins the prize for the worst technical
writing I ever saw. But, do some Google
searches, go to some Web sites, and see
that just some fairly simple SQL statements
are enough for such administration work.
So, get a collection of little SQL files,
run them through the wonderful, fantastic,
we're lovin' it, SQLCMD.EXE, document
the little files and their usage, and, fine --
f'get about Management Studio.
Basically, right, really prefer
command lines to GUIs! GUIs? Far
too difficult to understand,
get to work, script,
document, etc. We'll let the
cognitive psychologists at Xerox
PARC, Steve Jobs, etc. play with
direct manipulation GUIs, and we'll
stay with command lines, scripts
driving command lines, and a text
editor writing the scripts. Sorry
'bout that. To each their own.
If you like GUIs, then go for it.
YMMV.
WPF? Maybe that boils down to Windows
Forms for a native Windows application,
but our only GUI is HTML and CSS
with the little JavaScript ASP.NET writes
for us. If WPF boils down to HTML elements,
then, s...
It seems we share a similar philosophy. My SQL code is actually generated by the client. The server also generates its own SQL code, and does its own DB admin (create and drop tables, insert seed data and so on).
I think I need to look into TCP/IP sockets though. I have a very simple WCF service that accepts a byte array, and returns a byte array. No more, no less. The back-end deserializes the bytes and does what it needs to. WCF configuration is a Night! Mare! I think someone got completely spannered on the dependency injection koolaid. My service is a single method, and I spend more time babysitting XML in Web.Config than I do writing the service...
And yeah, with white space and comments my code base is around 120 LKOC. Just under 140 if I include the Windows Phone client.
Long ago I concluded that in tools,
ease of use was tools that were
reliable, did fairly simple things,
and were easy to understand how to
use and not tools that tried to do
a lot, do favors, anticipate what I wanted,
and do more for (to!) me!
So, in a kitchen, I don't want a hot dog
cooker and, instead, can, depending on
what I want, just use a pot and with
water and boil the hotdogs, use a skillet
with some oil and fry the hot dogs, or
go on the back porch, build a charcoal
fire, and broil the hotdogs. Besides, for
a hotdog cooker, how to clean the darned
thing! And have to get it out of storage,
set it up, etc. No thanks.
For cutting onions, use my best three tools
in a kitchen, a good French chef's knife,
a cutting board, and my hands. Works great
also for potatoes, carrots, cabbage, garlic,
and much more.
In a shop, have saws, hammers, files, wrenches,
screwdrivers, a drill plate, drill bits,
a nice, variables speed, reversible 3/8"
electric (not battery powered -- don't want
to mud wrestle with batteries that run down,
need charging, go dead, wear out, get weak, need to
be replaced, etc.) drill. Also
socket wrenches, etc. But lots of automatic
tools, e.g., a screwdriver that has a spiral
shaft that push on to turn a screw, don't want.
To sharpen a kitchen knife? Sure, just use
whatever grit size sand paper, usually
silicon carbide, want, put the paper flat
on the cutting board, and sharpen away.
Simple tools, that do simple things, and are
reliable and easy to understand. Then, build
more on those.
So, just use TCP/IP raw sockets and build more
on those.
For a session state server, use TCP/IP raw sockets,
de/serialization, and two collection classes.
Piece of cake, no use of CONFIG whatever, no
use of XML, only a few pages of documentation,
lots of good, old code samples, rock solidly
reliable ("TCP/IP sockets are the workhorse of
all of the Web and Internet")
etc. By far the
easy way.
http://iactionable.com is a .NET/C# start-up. We're completely hosted in Windows Azure as well. We also went through the Microsoft BizSpark program which is amazing and I highly recommend it.
At Tachyus (http://tachyus.com) we have made a huge bet on F#, and it has paid off in spades. The back end of our SaaS product is 99%+ F#, and so far we have had a great experience using Azure for hosting. Our iOS apps are also built using 99%+ F# (using Xamarin, on Mono rather than .Net). The language allows us to write highly expressive code, and fewer lines of code overall.
Using a Microsoft language has given us huge productivity benefits (most notably Visual Studio and Azure support). There is a fantastic F# community (http://fsharp.org) which is untethered to Microsoft, and it's exciting to see the language grow as an open-source and cross-platform tool.
How does this compare to OCaml or Haskell? Most of the "benefits" you've mentioned here aren't actually benefits, but par the course for a programming language no matter what stack you choose.
Visual Studio seems to be the only real benefit I'm seeing (and I agree, it's a very major benefit).
Compared to OCaml, F# has slightly nicer syntax, real multi-threading, and type providers (can e.g. automatically generate a type from a database schema). It lacks OCaml's awesome module system, higher-kinded polymorphism, OCaml's neat but rarely-used object system (it has C#'s object system hacked on instead), and on Mono at least it is generally slightly slower than OCaml.
In my view the .net libaries are probably the biggest advantage over OCaml and Haskell. Similar to how access to Java libraries gives Clojure an advantage over lisps like Common Lisp and Racket.
Oh, and if you want to use Windows without mingw then F# is a far better choice than OCaml or Haskell. The OCaml packaged manager doesn't even work properly on Windows, as far as I'm aware.
Thanks. Basically, creating a network of startup folks to help each other with tools and ideas. Job board to find talents. We also make https://dotnetfiddle.net/ to collaborate, help educate all things .net
Would love to see responses from the same users when the bizspark period is over. Seems like an idiotic choice to go vendor lock-in, small community, IMO sheltered mentality, high license fees (after bizspark), and difficult to automate operating systems. I suppose if you don't need a lot of machines it's not a problem yet, but seems like a lot of short sighted decisions.
I run S3stat and Twiddla on the .net stack and my BizSpark term has passed. It was in no way a big deal.
Yeah, servers cost money to provision. But then servers always cost money to provision regardless of your stack. Even with license fees, the MS stack wins for me because my entire server farm fits on three boxes instead of the twelve I'd need to get the same firepower on a typical rails stack. The extra few thousand in full price server licenses is just noise because really, we're talking about a business here, not a hobby.
The bottom line is that if your business is going to fail because of a single $5,000 invoice, it's debatable whether it was ever a business to start with. The whole reason we all build SaaS businesses in the first place is the 95%+ profit margins. Fretting about what happens within that 5% that makes up the expense column seems a bit silly.
Even without BizSpark, I bet I'll build the next product on the same stack. The math just plain works out.
The project I work on isn't a startup per se but it's not completely dissimilar. We use:
* ASP.NET for web with SQL Server + EF for the database and data access
* Xamarin for mobile and OData for data access (back to our ASP.NET sites)
The CLR is great because it's always been fast enough for our applications and every so often you get something for nothing. For example, CLR 4.5 brought better GC and RyuJIT is bringing better code generation. NET Native might give us even better performance.
LINQ is amazing if you know your IQueryables from your IEnumerables and the difference between an Expression<Func<T, bool>> and a Func<T, bool>.
Hosted in a private datacentre, not using Azure but we've got our eye on it (provisioning resources in the Azure Portal seems to get easier and easier than doing it ourselves).
New Relic for monitoring the web sites.
My biggest gripe (and it's not that big) is that within the Microsoft ecosystem/community everything works great but once you go outside it things are less well supported. Some less-popular-but-wow-that's-useful Javascript libraries don't come as NuGet packages. New Relic's .NET monitoring seems good but second fiddle to their other stuff.
After that I'd say Xamarin is letting the team down. Every second or so release of theirs fixes two bugs but adds another one.
Keeping an eye on Application Insights. It looks like it integrates nicely with Visual Studio Online, and VSO/TFS actually looks quite nice in parts (e.g. Bamboo for CI is largely geared towards Java apps not .NET but TFS' Release Management looks promising). I have my eye on VSO/TFS too but right now it looks like pros do not outweight the cons vs. our Atlassian applications.
If you've got enough processing power and memory and a fast SSD to run Visual Studio + ReSharper it's coding heaven.
98 comments
[ 4.7 ms ] story [ 199 ms ] threadAzure is a bit hit and miss. Its brilliant for getting something up an running quickly (using websites / SQL Server), but is a little flaky at scale.
Key problems include connection issues with SQL Server, connection issues with their hosted Redis service, pricing of SQL Server when using advanced features like geo-replication.
All in all though, its a pretty good development experience once you get your head around the fact that in the cloud services fail and there is nothing you can do about it except plan for it.
Oh and the Bizspark program they have gives you $100 worth of free hosting on Azure which is always nice.
What sort? If it's intermediate connection problems .NET 4.5.1 added Connection Resiliency to ADO.NET [1]. If you're using a recent enough version of Entity Framework it goes even further [2].
[1] http://dpaoliello.wordpress.com/2014/03/30/connection-resili...
[2] http://thedatafarm.com/data-access/ef6-connection-resiliency...
We have our own retry logic, which also logs the issue so we are aware of how frequently errors occur while a command / transaction is being executed.
This is using SQL Azure with the "Business" tier, so it will be interesting to see how the new (much more highly priced tiers) Standard and Premium tiers go.
https://everymove.org/
Might be worth checking out bizspark [2], as I know it lists lots of startups that are using a .net stack.
Also probably worth mentioning what you're compiling the list for if you want more responses from HN users...
More info: We actually don't host on Azure (Web Sites not flexible enough for us), but use a mixture of AppHarbor [3] (awesome product and team), and various Amazon web services.
[1] - https://www.openrent.co.uk
[2]http://www.microsoft.com/bizspark/partners/startups.aspx
[3] - https://appharbor.com
Would you care to share any specifics? I'm curious to know what you're trying to do that doesn't work on Azure.
One example - if you have any processing in the application_startup, Web Sites won't work for you. Applications are randomly killed and restarted, and don't allow for a startup time, meaning outages when this happens. Customer support suggested using a fail over to work around this, but the fail over only kicks in once your app has been down for a certain amount of time - so you'll still have down time.
a) https://github.com/HangfireIO/Hangfire b) http://azure.microsoft.com/en-us/documentation/articles/web-...
Sure - we could re-architecture the app so that isn't a requirement, but then I'm making design decisions based on Azure constraints. Why would I when there are alternatives like AppHarbor?
It's hard to say no when they give you so much free stuff for a startup-style business.
free servers are free servers.
http://azure.microsoft.com/en-us/documentation/articles/virt...
http://azure.microsoft.com/en-us/pricing/details/virtual-mac...
For the most part, the stuff that runs on Azure doesn't have a discrete licensing cost. You pay the hourly rate for the resource.
Also using SQL Azure and Redis for data storage/caching - it's been mostly positive so far. The downside with Azure has been the portal/management experience. The current UI is somewhat sluggish and disorganized, and the new portal tile UI is extremely confusing to navigate.
Overall it's been a pretty pleasant experience (maybe minus dealing with web.config files).
Seriously. I don't know what they were thinking. I don't mind the current portal. It does take seem sluggish with all the ajax/loading but at least I know where everything is. The new portal needs to be completely redone.
Only downside is that for something like a customer-facing portal, the identity-management is tied to Windows-specific features, for now - so have had to build a custom solution for this that runs on Linux. Waiting for ASP .NET vNext and its Identity solution when it becomes slightly more mature.
EDIT: Also evaluating a move to Azure. Primary driver (for choosing the .net stack) has been prior experience with C#, .NET and Visual Studio
[1] https://octopusdeploy.com
http://tachyus.com/ http://jet.com/
There are others as well (I just don't recall their names right now) -- take a look on http://fsharp.org for more links.
http://pitsolutions.io/
All .net/sql server, jquery on the front end with websockets.
Bizspark is also great! $150 per month of free credit really helps - especially at the early stages.
For C#, not interested: The syntax borrows from the deliberately idiosyncratic syntax of C, and the Visual Basic syntax is more verbose, easier to learn, teach, and read, and, thus, less error prone, is as a programming language in its semantics, features, and functionality essentially equivalent to C#, that is, the difference is mostly just syntactic sugar, and apparently is about as good as C# or anything else at getting at the CLR and the .NET Framework.
For F#, people back to Backus have been working on functional programming, and, for more than just curiosity, and certainly for the work of our start-up, we're not impressed or interested, in that or logic programming, rule-based programming, or standing on our heads in the corner programming, etc. -- sorry 'bout that; we can agree to disagree, and YMMV.
We're quite pleased with Visual Basic .NET. A hat tip to the Microsoft Visual Basic group.
Main gripe: For the documentation, actually for all the documentation on MSDN, especially for SQL Server, please, please, please, get a least a C in technical writing 101. Our biggest problem in our start-up, far and away, much, much, much more difficult than everything else combined, literally, is the low quality of the technical writing at MSDN.
For JavaScript, Microsoft's ASP.NET writes some for us, but so far we have yet to write a single line of it and will delay doing so as long as we can, hopefully forever.
For ASP.NET, we are using just the basics, that is, with
etc. We have heard of MVC, looked at it a little, can see no reason for it or advantage in it, and intend to have nothing to do with it. Maybe better technical writing at MSDN would let us take MVC more seriously.We type into our favorite text editor and make no use of an IDE nor do we want to.
For developing code for Web pages, ASP.NET and Visual Basic work nicely together -- it works fine. Actually, it's nice.
For a session state store, we wrote our own using just instances of one class, de/serialization, TCP/IP raw sockets, and two collection classes. On an 8 core processor at 4.0 GHz, our session state store should be good for 11,000+ transactions a second; transactions is appropriate because the code is single threaded. Yes, on an 8 core processor we would run several instances with sharding.
As we go live, our server will be just a single full tower case with an 8 core processor, 32 GB of main memory, some SSDs for a special purpose particular to our start-up, and some disks, with Windows Server, SQL Server, IIS, ASP.NET, our Web pages, our session state store, and some specialized back-end servers. The software and architecture are scalable via just simple sharding. We have little or no intention of using the cloud soon or ever.
As we go live and grow, after the issue of the MSDN documentation, no doubt, and closely related to the documentation issue, our biggest concern will be Windows Server, SQL Server, and IIS installation, configuration, updates, security, monitoring, management, performance, administration, reliability, backup, and recovery -- little things like those. But from some of the just astounding successes Microsoft has running server farms with their software, clearly terrific results are possible; maybe we will be calling for some high end technical support.
That's what we are doing!
...if not, would you mind letting us email your developers to try and save them from career suicide?
I'll let them all know that they have a choice: (1) Make money doing the work to make our software and Web site good, our users happy, and our start-up successful or (2) grow their resumes for jobs elsewhere.
With (1), they get to help build something important. With (2) they get to add buzz words of questionable utility for unknown projects of questionable value. YMMV.
I'd say obvious ... is obvious
Either way: LOL
No, what I wrote is what we're doing. Maybe there's some humor in there somewhere, but it's all simple and obvious and makes good sense to us.
Just in case you guys aren't clear on the intent of the post, another submission by this user talking about cats breaking Firefox:
https://news.ycombinator.com/item?id=8541621
Ah, good to get some laughs.
But if your kitty cat, puppy dog, or baby walks across your keyboard, or if something falls on your keyboard, etc., and suddently Firefox closes after 10 seconds, and keeps doing that, as you keep restarting Firefox, no matter what, you may very well like my post and its solution.
Or, you can do a Google search and find that the symptoms are common, and find that the recommended solutions range from reinstall your anti-virus software, install a new version of Firefox, reinstall device drivers, ..., buy a new keyboard, give up your kids, divorce your spouse, buy a new computer, submit to full castration, move to the woods in northern Canada, or worse.
Instead, just use the solution I found. Piece of cake.
It's easy to suspect that my simple discovery will solve a major fraction of all the instances of that nasty, fairly common problem, hilarious or not.
Exercise: Before reading my solution, guess what it is! Record your guesses here before reading my solution.
Hilarious? Maybe. Obvious? No. Useful? Yes. Difficult? No. Fast? Yes. Easy? Definitely. Better than the suggested alternatives? By some light years.
What it does: http://bit.ly/1rqJ0NG
Security aspects: http://bit.ly/1tgHUcD
2FA/OTP ideas: http://bit.ly/1sQyQtq
Screenshots: http://bit.ly/1rMIWbd
For WCF, LINQ, and WPF, we looked at the documentation, and it was clear that just working through the tough parts of the documentation alone would be much more work than just writing our code directly. Moreover, any bugs, security problems, need for updates, etc. of WCF, LINQ, and WPF we just neatly avoided.
And we saved maybe a lot of address space.
That is, it looked to us like, for us, YMMV, WCF, LINQ, and WPF are a candle not worth the match. I can believe that in some situations those three could have some value; for us, I don't see the value.
I mean, WCF boils down to TCP/IP raw sockets, right? Well, the API to raw sockets is about the easiest I/O one could hope for, nearly as easy as the ancient Basic statement PRINT or the same in C, etc. I tried for several days to make sense out of WCF, came up with zip, zilch, zero, nichts, nil, nada, and gave up, but I learned raw sockets in about three hours one afternoon decades ago. To heck with WCF.
For LINQ, that boils down to just SQL, right? Well, SQL was supposed to be really easy to use, is profusely documented, and has been, for decades, has long been an ANSI standard, has been tested in various ways, and with astounding severity, around the world, for decades, right? So, writing some SQL is not so tough. Getting a connection string to SQL Server? Yup, that took two weeks of mud wrestling, but the SQL statements were easy enough to write. SQL's fine. Very glad to have it. SQL Server connection string mud wrestling? Did I mention some bad documentation? The full power of the Microsoft Corporation still is unable to document how to write SQL Server connection strings. The only way I learned was via Google searches wherever, and then I did some organized trials of essentially all possible combinations of everything involved until it appeared to work. I still don't know just why what worked did and what didn't work didn't. Cave men with burnt sticks wrote better documentation on cave walls.
For our SQL Server database schema, that is, the specifications of the tables, the columns, etc., we have a little file, just awash in comments, nicely clear and easy to read, that we run through the wonderful SQLCMD.EXE -- "Look, Ma, no GUIs!". And no clicking! Instead, just type the name of a little script, and presto, boom, have a new database created just as want, nearly no chance of anything going wrong. It's better than most sex!
For the SQL Server Management Studio, can use it read only a little and otherwise just can't make sense out of most of the screens, windows, sub-windows, check boxes, terminology, concepts, etc.
So, for SQL Server administration, just back to the simplest little SQL statements, mostly industry standard.
The SQL Server documentation of users, logins, etc. wins the prize for the worst technical writing I ever saw. But, do some Google searches, go to some Web sites, and see that just some fairly simple SQL statements are enough for such administration work. So, get a collection of little SQL files, run them through the wonderful, fantastic, we're lovin' it, SQLCMD.EXE, document the little files and their usage, and, fine -- f'get about Management Studio.
Basically, right, really prefer command lines to GUIs! GUIs? Far too difficult to understand, get to work, script, document, etc. We'll let the cognitive psychologists at Xerox PARC, Steve Jobs, etc. play with direct manipulation GUIs, and we'll stay with command lines, scripts driving command lines, and a text editor writing the scripts. Sorry 'bout that. To each their own. If you like GUIs, then go for it. YMMV.
WPF? Maybe that boils down to Windows Forms for a native Windows application, but our only GUI is HTML and CSS with the little JavaScript ASP.NET writes for us. If WPF boils down to HTML elements, then, s...
I think I need to look into TCP/IP sockets though. I have a very simple WCF service that accepts a byte array, and returns a byte array. No more, no less. The back-end deserializes the bytes and does what it needs to. WCF configuration is a Night! Mare! I think someone got completely spannered on the dependency injection koolaid. My service is a single method, and I spend more time babysitting XML in Web.Config than I do writing the service...
And yeah, with white space and comments my code base is around 120 LKOC. Just under 140 if I include the Windows Phone client.
So, in a kitchen, I don't want a hot dog cooker and, instead, can, depending on what I want, just use a pot and with water and boil the hotdogs, use a skillet with some oil and fry the hot dogs, or go on the back porch, build a charcoal fire, and broil the hotdogs. Besides, for a hotdog cooker, how to clean the darned thing! And have to get it out of storage, set it up, etc. No thanks.
For cutting onions, use my best three tools in a kitchen, a good French chef's knife, a cutting board, and my hands. Works great also for potatoes, carrots, cabbage, garlic, and much more.
In a shop, have saws, hammers, files, wrenches, screwdrivers, a drill plate, drill bits, a nice, variables speed, reversible 3/8" electric (not battery powered -- don't want to mud wrestle with batteries that run down, need charging, go dead, wear out, get weak, need to be replaced, etc.) drill. Also socket wrenches, etc. But lots of automatic tools, e.g., a screwdriver that has a spiral shaft that push on to turn a screw, don't want.
To sharpen a kitchen knife? Sure, just use whatever grit size sand paper, usually silicon carbide, want, put the paper flat on the cutting board, and sharpen away.
Simple tools, that do simple things, and are reliable and easy to understand. Then, build more on those.
So, just use TCP/IP raw sockets and build more on those.
For a session state server, use TCP/IP raw sockets, de/serialization, and two collection classes. Piece of cake, no use of CONFIG whatever, no use of XML, only a few pages of documentation, lots of good, old code samples, rock solidly reliable ("TCP/IP sockets are the workhorse of all of the Web and Internet") etc. By far the easy way.
https://github.com/clojure/clojure-clr
https://cognitect.wufoo.com/reports/state-of-clojure-2014-re...
There was an announcement of Clojure in Unity3d [1] a couple weeks ago which is ClojureCLR.
https://github.com/arcadia-unity/Arcadia
Using a Microsoft language has given us huge productivity benefits (most notably Visual Studio and Azure support). There is a fantastic F# community (http://fsharp.org) which is untethered to Microsoft, and it's exciting to see the language grow as an open-source and cross-platform tool.
Visual Studio seems to be the only real benefit I'm seeing (and I agree, it's a very major benefit).
In my view the .net libaries are probably the biggest advantage over OCaml and Haskell. Similar to how access to Java libraries gives Clojure an advantage over lisps like Common Lisp and Racket.
Oh, and if you want to use Windows without mingw then F# is a far better choice than OCaml or Haskell. The OCaml packaged manager doesn't even work properly on Windows, as far as I'm aware.
And https://www.calendartree.com/ (startup by Dilbert's Scott Adams + others) are C# / SQL site, on their own servers.
Website: http://www.moneysoft.com.au/ App: https://secure.moneysoft.com.au/
Yeah, servers cost money to provision. But then servers always cost money to provision regardless of your stack. Even with license fees, the MS stack wins for me because my entire server farm fits on three boxes instead of the twelve I'd need to get the same firepower on a typical rails stack. The extra few thousand in full price server licenses is just noise because really, we're talking about a business here, not a hobby.
The bottom line is that if your business is going to fail because of a single $5,000 invoice, it's debatable whether it was ever a business to start with. The whole reason we all build SaaS businesses in the first place is the 95%+ profit margins. Fretting about what happens within that 5% that makes up the expense column seems a bit silly.
Even without BizSpark, I bet I'll build the next product on the same stack. The math just plain works out.
* ASP.NET for web with SQL Server + EF for the database and data access
* Xamarin for mobile and OData for data access (back to our ASP.NET sites)
The CLR is great because it's always been fast enough for our applications and every so often you get something for nothing. For example, CLR 4.5 brought better GC and RyuJIT is bringing better code generation. NET Native might give us even better performance.
LINQ is amazing if you know your IQueryables from your IEnumerables and the difference between an Expression<Func<T, bool>> and a Func<T, bool>.
Hosted in a private datacentre, not using Azure but we've got our eye on it (provisioning resources in the Azure Portal seems to get easier and easier than doing it ourselves).
New Relic for monitoring the web sites.
My biggest gripe (and it's not that big) is that within the Microsoft ecosystem/community everything works great but once you go outside it things are less well supported. Some less-popular-but-wow-that's-useful Javascript libraries don't come as NuGet packages. New Relic's .NET monitoring seems good but second fiddle to their other stuff.
After that I'd say Xamarin is letting the team down. Every second or so release of theirs fixes two bugs but adds another one.
Keeping an eye on Application Insights. It looks like it integrates nicely with Visual Studio Online, and VSO/TFS actually looks quite nice in parts (e.g. Bamboo for CI is largely geared towards Java apps not .NET but TFS' Release Management looks promising). I have my eye on VSO/TFS too but right now it looks like pros do not outweight the cons vs. our Atlassian applications.
If you've got enough processing power and memory and a fast SSD to run Visual Studio + ReSharper it's coding heaven.
I love AI. I hate that they don't even provide a clue to what the pricing model for this will be though.
The good will become perfect soon enough:
http://www.hanselman.com/blog/IntroducingGulpGruntBowerAndNp...