I began writing C# in 2004. I've been writing it since for business and pleasure. Since Microsoft began adopting a more open source approach, it's been, well, amusing to see the open source culture collide with has been historically a closed system.
"Why isn't there a free, open package that solves hard problem X, it's 2015 after all. How preposterous!" The naivety displayed in these kinds of statements is amusing. There are probably many solutions to hard problem X locked away in proprietary "Microsoft Shop" code bases around the world. It's incredibly daft to assume otherwise. Does this approach lead to a lot of duplicated effort- yes; are there a lot of hacked together half working solutions out there- yes; has the .NET community been ok with this- yes. As is the culture of .NET. It's the fine art of not giving a shit because you're going to get paid anyways.
"Oh these poor .NET bastards, they're just sooo clueless of the world around them; they only know Windows." I'm sure this could be said of just about anyone. All tech stacks have their stars and fry cooks. As with many things, it's a matter of how you want to dedicate your time. Could I spend my time focused on file system design, memory issues, and network architectures. Absolutely! It's great that people enjoy this stuff; I personally don't. It's boring to me same reason I don't enjoy futzing around with Linux. I don't care about how it works; just that it does work. When I write for the .NET/C# stack, my focus is on the business problem. How do I impact the end-user (ie Shannon over in accounting, or little Timmy dipshit in Iowa) in a positive way.
"VS also has this really nasty habit of creating "csproj" and "sln" files. I hate those things." this is like bitching about make files. It's beyond silly. Could it be improved- probably, does it need to be- no. I think make files are a horrible way to do things, do I bitch about it- no. I understand that that is the preferred approach of the environment. Learn what I need to do to make it work and get on with my day. And really, these types of complaints are just childish. You're a professional. Deal with it.
As far as IIS is concerned, we can have a ceremonial burning of the source code one day. That product is beyond useless.
The selling point of C#/.NET isn't it's community- it's its productivity. A company can hire a small team of developers and they can crank out a bunch of code in short order to solve some specific problem. The code will be written the ".NET way" not because that's what's best for performance, but because that's what's best for development. Same thing happens in other technology stacks. Code is written to follow a well followed pattern by its community so that new hires and other developers can quickly suss out what's going on without having to stop and think. It's the same song and dance of using third-party libraries. Bit like a royale with cheese instead of a big-mac. Dress it up different, but the same principles are at play.
Fundamentally, there's going to be some cultural exchange between the traditional .NET crowd and the open source crowd. Both parties stand to learn a lot from one another, and have lots of opportunities to discover overlap. Rather than throwing in the towel and saying .NET is bullshit and used by dullards who solve inconsequential problems is short sighted. Find a place for .NET in your stack, look for opportunities to mix it in with your existing open source technologies. If you can't find a spot for it, then move on to whatever works for you. It's not rocket science.
The developer salary costs seem really outlandish. 500k euro for a "top notch developer" and 250k euro for "supporting developers". Where are these estimates coming from?
500k is not that outlandish for a system like this. Cameron Purdy, who developed Tangosol (now Oracle) Coherence said that he regularly turned down $500k job offers. Bear in mind that their idea of "top notch" is not what gets bandied around here as "rock star". They're not programming Rails. They're talking people who have had their shit together since day one, have always been top of their class even after they got into the best universities, and have applied themselves their whole lives to the theory and practice of building big systems. I've built some biggish systems but I still spent a large amount of my university years and youth generally studying beer, skirts and house music. It makes a difference, I'm a long long way from what they're talking about.
Here's how I would think about it if I were building this. The total hardware costs are 168M, and the total personnel costs are 4M. Say I pay $500K instead of $200k and in doing so I get Jeffrey Dean instead of someone like me (I suspect I might have to pay more than $500k for Jeffrey Dean but bear with me). My costs have doubled but the efficiency of the system might be 5x or 10x better because I'm just quite good at my job and he's a total legend. That efficiency scales the total hardware cost, which dwarfs the personnel cost. I'd say $500k starts to look pretty cheap at that scale.
It's the cost of renting a developer with security clearance from BAH. Snowden would likely be in the same salary band as a "supporting developer." He was taking home $122K, thus his actual cost to the government was likely $250-$300K.
If we are uploading cheques and licenses, why not just have a form with the respective upload sections for each document. Sure, people might get the two backward by accident, but is that error rate really any worse than the false positive rate of the proposed solution.
If you are going to go the machine learning route, then it really only makes sense if you go all the way and do some OCR on the documents to pick out the meaningful information to prepopulate some input screen that would likely appear after submitting those documents.
Yes, content analysis can be greatly simplified using symbolic inputs. GPS Tags in images, User input in OP's check example and most industrial pipelines used sophisticated barcode scanners to scan objects very quickly, but the cameras are at a fixed distance/height from the object and the objects are aligned in a particular direction. Some purists would argue that this is not computer vision, but it makes for some excellent engineering, and solves some hard problems very well.
While the actual case study makes for an interesting read -especially for someone who lives in Colorado - the numerous typo's, spelling errors and grammatical mistakes greatly takes away from the message. Did anyone bother to proofread this document at Calleam Consulting before releasing in back 2008?
"The interview is still a traditional environment." --Jaime Fall, vice president of the HR Policy Association. As quoted in the article.
Something about his use of the word traditional sets me off. Oh well, they made a "jobipedia," whatever that is. If it helps graduates get past the often capricious nature of HR drones then I won't complain.
"Why isn't there a free, open package that solves hard problem X, it's 2015 after all. How preposterous!" The naivety displayed in these kinds of statements is amusing. There are probably many solutions to hard problem X locked away in proprietary "Microsoft Shop" code bases around the world. It's incredibly daft to assume otherwise. Does this approach lead to a lot of duplicated effort- yes; are there a lot of hacked together half working solutions out there- yes; has the .NET community been ok with this- yes. As is the culture of .NET. It's the fine art of not giving a shit because you're going to get paid anyways.
"Oh these poor .NET bastards, they're just sooo clueless of the world around them; they only know Windows." I'm sure this could be said of just about anyone. All tech stacks have their stars and fry cooks. As with many things, it's a matter of how you want to dedicate your time. Could I spend my time focused on file system design, memory issues, and network architectures. Absolutely! It's great that people enjoy this stuff; I personally don't. It's boring to me same reason I don't enjoy futzing around with Linux. I don't care about how it works; just that it does work. When I write for the .NET/C# stack, my focus is on the business problem. How do I impact the end-user (ie Shannon over in accounting, or little Timmy dipshit in Iowa) in a positive way.
"VS also has this really nasty habit of creating "csproj" and "sln" files. I hate those things." this is like bitching about make files. It's beyond silly. Could it be improved- probably, does it need to be- no. I think make files are a horrible way to do things, do I bitch about it- no. I understand that that is the preferred approach of the environment. Learn what I need to do to make it work and get on with my day. And really, these types of complaints are just childish. You're a professional. Deal with it.
As far as IIS is concerned, we can have a ceremonial burning of the source code one day. That product is beyond useless.
The selling point of C#/.NET isn't it's community- it's its productivity. A company can hire a small team of developers and they can crank out a bunch of code in short order to solve some specific problem. The code will be written the ".NET way" not because that's what's best for performance, but because that's what's best for development. Same thing happens in other technology stacks. Code is written to follow a well followed pattern by its community so that new hires and other developers can quickly suss out what's going on without having to stop and think. It's the same song and dance of using third-party libraries. Bit like a royale with cheese instead of a big-mac. Dress it up different, but the same principles are at play.
Fundamentally, there's going to be some cultural exchange between the traditional .NET crowd and the open source crowd. Both parties stand to learn a lot from one another, and have lots of opportunities to discover overlap. Rather than throwing in the towel and saying .NET is bullshit and used by dullards who solve inconsequential problems is short sighted. Find a place for .NET in your stack, look for opportunities to mix it in with your existing open source technologies. If you can't find a spot for it, then move on to whatever works for you. It's not rocket science.