Related
I'm in the research phase of my next computer build. I have the idea in my head of running a hypervisor as the base of the system, but i would want to be able to take a shot at programming opencl with one of the OS's installed on the hypervisor...and maybe some gaming. Would i have enough access to the GPU to be able to achieve this effectively, or am i better off installing an OS that i will do development(and gaming) from and then just virtualize any systems on top of that?
what are your recommendations for a hypervisor, vmware, microsoft or other?
sidenote: Recently graduated with a BS in CS, the massive parallel processing seems like a good idea of something to learn, won't be doing any 'real'/major development work. also, i'm aware that CUDA is more mature in it's development, but i'm sticking with opencl for a few reasons, so please don't try to persuade me.
thanks for your input!
dave k.
whats your focus? Virtualisation or OpenCL?
Hak5 did a nice walkthrough of debian based virtualisation environment ProxMox, but I don't know whether it allows virtual hosts hardware access or OpenCL virtualisation.
X86 and AMD64 are the most important architectures for many computing environments (desktop, servers, and supercomputers). Obviously a JIT compiler should support both of them to gain acceptance.
Until recently, the SPARC architecture was the logical next step for a compiler, specially on high-end servers markets. But now that Sun is dead, things are not clear.
Oracle doesn't seem to be really interested in it, and some big projects are dropping support for that architecture (Ubuntu for example). But on the other hand, the OpenSPARC initiative intended to open source recent processors is quite promising, meaning that a lot of manufacturers could implement and use SPARC for free in the near future.
So, is SPARC still a good choice as the next target architecture for a JIT compiler? Or is it better to choose another one (POWER, ARM, MIPS, ...)?
I don't know any more than you about SPARC's future. I hope it has one; it's been tragic how many good architectures have died out while x86 has kept going.
But i would suggest you look at ARM as a target. It isn't present in big server hardware, but it's huge in the mobile market, and powers all sorts of interesting little boxes, like my NAS, my ADSL router, and so on.
Your next target architecture should definitely be ARM - power consumption in large datacenters is a huge issue and the next big thing will be trying to reduce that by using low-power CPUs; see Facebook's first attempt on this.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I work on a team with three other developers and one business analyst writing internal business applications. We're primarily building apps in ASP.Net, and do so in a very 2003-ish way. It's like going back in a time machine. Although two of the other developers are amenable to learning new things, one of the developers is not. He's the type who thinks he's the strongest developer in town, and that if he doesn't understand a new tool within 5 minutes then he just needs to build his own. He also doesn't recognize agile development, TDD, or basically any non-Microsoft-blessed tool or method. He even considers source control from anything other than SourceSafe to be dangerous. To his credit, he's a brilliant programmer, just not someone interested in software development.
So the only way I can get consensus is if a tool is really easy to use. Once we hit a single snag, he'll lose faith in a "I told you so" sort of way.
So what set of tools should I use to get us into a modern source control system, TDD, and CI? The obvious choice in my situation seems like it would be Microsoft's TFS, but I doubt I could get our thrifty and apathetic management team to spend the extra money (they already think MSDN Pro is too much).
Basically, what is the easiest set of tools to get going with Source Control, TDD, and CI for a .Net 2008/2010 environment?
I wouldn't recommend dumping all these tools and methodologies on your team at once, take baby steps. Introduce one at a time. Some will come naturally.
There are many good choices, but I can personally recommend these:
Source control: Subversion with TortoiseSVN and Ankh or VisualSVN
Continuous Integration: CruiseControl.NET
TDD tools: NUnit + your mocking framework of choice (I use NMock, though it's a bit old-school). I agree with commenter Eric that TestDriven.NET is a must-have, particularly if you want to make this easy!
These are easy to get started with because they're all good products, reasonably to very well-documented, and widely-used (so it's easy to get help).
It's always going to be difficult to introduce new tools if you can't build a consensus. Focus on building the consensus, rather than on the tools.
SVN is very good (with Ankh and TSVN), but it can be a bit surprising to people used to SourceSafe.
TDD is a technique, rather than a toolset, so you need books, blogs, etc. For tools to support it, NUnit or MSTest. Continuous Integration is a must-have. CruiseControl.Net is pretty good (though a bit difficult to configure initially). Consider also TeamCity.
Do you have a bug-tracking system?
Oh, and if your management team is that apathetic, consider quitting.
Update: you've said that they're not so much "apathetic" as "hands-off". Question: are they really hands-off, and will they let you move things along? Or are they "status quo" -- "it ain't broke, so don't fix it, and don't rock the boat"?
I think you can make a really really good case that within the last two years Agile has become completely and totally embraced by Microsoft. I know for a fact that the Codeplex, MEF, and ASP.NET MVC teams are quite steeped in it. I also think that visual studio and parts of the windows 7 team are Agile. Also consider that Visual Studio 2010 includes out-of-the-box refactorings that don't really make much sense outside the context of TDD and that Agile is the default project management template for TFS and a picture of a corporate culture that is quite different from the one of years past starts to emerge.
As for specific tools. TFS is OK for source control but I find it very heavyweight and finicky. Others have mentioned Subversion but if you're worried about MS blessings you might have better luck jumping straight to Mercurial. Its a more advanced SCM but it is now supported natively by Codeplex and has excellent windows integration. I've never used it but I am in deep tool-love with it's cousin git.
Test driven development: Start with MSTest, its not as slick as anyone would like but its not the worst thing in the world. I would also recommend MbUnit which has all of NUnit's features along with some good support for the integration tests that you will probably be writing by accident as you are starting out with testing. Oh, and if you have customization freak I would urge him to look at XUnit.Net.
Mocking: The choice is basically Rhino Mocks or MoQ. Here's a quick intro I wrote for Rhino Mocks that goes over all the basics. That being said, the trade off seems to be more documentation for RM versus a very mildly less error prone syntax for MoQ.
Test Runners: If you start out with MSTest you'll notice that you can get a significant speed boost in your test runs by using TestDriven.Net, resharper or coderush rather than the built in test runner. That being said, don't underestimate the standalone test-runners. They can be quite good every once in a while. I heavily recommend Gallio Icarus runner which comes with MbUnit.
I want to echo what George Mauer has said and suggest starting with MSTest for your unit testing. It's right there in the box to begin with Visual Studio, this will help in your cause as it's "MS blessed".
I would start with unit testing and take it from there, after a few months of "look how easier our life is now we have these tests automated" I'd take it up a notch. Consider adding something like Selenium or WatiN to the mix. Once you're rolling with that, get your CI server up. "Wouldn't it be great if we didn't have to start off all these tests manually?..."
I guess a decent SCM might be a sticking point. SourceSafe is better than nothing. Perhaps start using Mercurial or Git yourself? Show those open to the change the benefits, eventually your stubborn dev will come around when others around him are wanting to switch. Hopefully, he'll find it harder to shout if he's in the minority.
Check out http://www.viget.com/extend/effectively-using-git-with-subversion/ for ideas with mixing up different SCMs.
I also want to +1 mxmissile for saying to take things slowly. I think you'll find it very difficult to introduce all these changes in one go. It's a lot to take in at first if you're not used to it. Try to pick the part you're weakest on, or will add the most value and build up from there.
Good luck!
One tool that got me hocked on TDD is TestDriven.Net which puts the test results in the Output window. I mapped this to the F8 key and the productivity gain is superb; write a test, press F8 and see this results in the output window.
One suggestion I also have to differentiate between having Unit Tests and doing TDD. I have found that TDD can be hard to push on to a team, while; unit, integration or functional tests are an easier sell. Having a bunch of tests that saves an hour going through a manual test day after day is a big win.
After a while people will start to appreciate some new ideas if it is helping them in their daily life. Then you'll be able to introduce a build server, and move away from SourceSafe.
In .NET environments, Microsoft Visual SourceSafe is most frequently used. (but it costs). Next to that you can opt for SVN or GIT. Git is more recent (and gaining popularity). It's easier to work with than SVN once you get it.
http://git.wiki.kernel.org/index.php/GitSvnComparison might help with your decision.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
One thing that I keep hearing in reference to ASP.NET and MSFT technologies is that they cost money to use. Often when they are being compared to open source languages someone will mention that one factor in favor of open source is that it's free (to an extent). My question is, when does ASP.NET actually cost money to use in terms of using the proprietary technology?
Understandably there are the hosting fees, but I'm curious about the fees outside of these hosting fees. I'm especially curious about this as it relates one-person smaller-site development (non-team/large enterprise). Any help is appreciated.
(edits)
Some excellent answers. Much appreciated
The projects that I'm looking to use the technologies for would be personal sites and very small business sites (1 or 2). The intent would of course be that these projects get much bigger. It seems that for commercial production, fees will apply. What about just basic dynamic "shared hosting" sites that provide information?
You have to measure many things when you determine cost. We recently went through an evaluation of platform choice by an outside vendor, and the recommendation is that we stay with a Microsoft.NET platform. Why? For us, the reason is that once you get to an enterprise-level product suite, the difference is not as big as people would like you to believe.
Purchasing Microsoft products is a sound choice. The initial cost might seem high, but keep in mind if you get Software Assurance on your purchase (Visual Studio, for example) you are entitled to free upgrades as long as you keep you SA current - and it is at a fraction of the cost of a repurchase. Many people think you need to buy the full retail version every time, and that is just not true. Work with a larger vendor, like CDW, to help with licensing questions. They got someone from Microsoft's Licensing Division on the phone with us and helped us choose what was right. Not high-pressured at all. They actually talked us down on some of the things we thought we needed.
MSDN subscriptions are great. I have one through my employer, but also used to maintain one personally. If you are a contractor/self-employed, it is an operational expense. Like buying full products, renewing a MSDN subscription is very inexpensive compared to a purchase, and especially considering what you get. The licensing within MSDN is rather generous, and since you are a one-person shop, if I read that correctly, one MSDN is more than enough for your non-production needs. Plus, the bundled Support Incidents are a nice plus, as well.
There are many versions of Visual Studio, from the Express Editions all the way up to the Team Editions. For example, we are rolling out Team Foundation Server right now, so our costs are obviously higher. For a startup or small shop, there are TFS hosting partners and you can get Team Explorer for free. Or you can mix and match, using Visual Studio for development and something like VSS, SVN, or countless other version control products out there.
Just because someone "goes open source", that does not mean that it is free. Yes, the platform choice might be free, and the tools might be free, but there is a definite chance that you will need a commercial library or component some day. Plus, nothing prevents you from going with Open Source products with Microsoft, either. There are many open source projects written in .NET that can be leveraged with your solutions, and Microsoft is becoming a lot more transparent. We are working on a very large, enterprise solution right now and we are using only one "commercial" product, outside of our development tooling. There is a lot of Open Source usage, and a lot of implementations cobbled from community musings and examples.
The one thing that often goes unmentioned is the human cost that goes into these decisions. Microsoft is hated by many and their solutions might not be the fastest or most robust (although I will take IIS7 on W2K8 over any other web server configuration any day) they are focusing on making people more productive at what they can do. You aren't just buying products with them, you are actually buying productivity. As someone who has worked in a few Open Source shops, I am very appreciative of all the things that they have gotten right and understand that free does not always mean better.
I have a "one-person" side business and I really recommend looking into an MSDN subscription. It will give you access to tools and technologies that you would not otherwise be able to get your hands on without going a la carte in a retail route. Talk with someone, like a CDW, to help you figure out your licensing needs. If it works out, definitely try that route. You can cover all your in-house needs in a one person shop with an MSDN subscription, most likely (for example, a lot of the products are available to install to you (as a user) up to ten times as long as the machines that they are installed on are "yours" and non-production. There are exceptions to that, but not many.)
If that does not work, try the free route. You can definitely use Mono for .NET Development, as well as the Express Editions. I know a few C# developers who swear by Mono and could not be happier.
Best of luck to you!
Often when they are being compared to open source languages someone will mention that one factor in favor of open source is that it's free (to an extent). My question is, when does ASP.NET actually cost money to use in terms of using the proprietary technology?
Usually when people refer to "cost" in the way you described, they're implicitly referring to TCO, or total cost of ownership. The cost is not an explicit cost in that you've paid for something directly, but rather the long-term price of using something over its lifetime.
For example, even if a particular proprietary technology is free, it may be more difficult to hire and find people who know about it to work on your project. Consequently, if it is less popular than some open-source equivalent, you may wind up paying more for the same amount of labor because appropriately talented staff will be harder to find and in higher demand.
Conversely, if an open-source product is free but has low mindshare or performs poorly, it may well be worth it to pay for an expensive, closed-source proprietary solution rather than having to learn the idiosyncracies of the open-source version.
Naturally, there is some controversy surrounding just how to measure TCO, with both camps having some valid points.
.NET is free
C# compilers are free
Certain versions of Visual Studio are free, and you don't actually need it to write for .NET anyway (though it really, really helps!)
There are many free online resources for learning .NET, such as http://asp.net
In short, there's no real cost to using ASP.NET other than the hosting fee of the website or options you might buy to make things easier (better versions of Visual Studio.)
There's more of an ideological divide, with open source guys on one side being pretty anti-microsoft and so claiming it's high cost to use. I wouldn't worry about them. ;)
There are a couple of good answers already, but I'd like to add "it depends".
joseph.ferris obviously works in a large organization, where the cost of switching platforms is going to be very, very expensive, so the cost of paying the licensing costs is much less that the cost of switching. Take a look at Jonathan Schwartz's blog entry for Mar. 11, especially the section titled "When Free is too Expensive" for another reason to go with fully-supported infrastructure.
But consider a couple of other scenarios.
First, there's the hobbyist, which is what you seem to be addressing - you want to play around with the technology, and maybe put up a website or three. There aren't any issues with privacy or scalability, so you can deploy your application on an inexpensive shared hosting solution. In this case, costs are pretty much irrelevant - whatever platform you pick, you can get free tools to get you started. Remember kids, the first hit is always free.
For a startup, things are a bit different. If the goal is to build a large website, the potential licensing costs can be daunting - it's probably going to a lot cheaper to go with open source. In addition to the production environment, you need to pay for development environments, testing, etc. Even for a small company, licenses may be more than they have in the budget - a single Windows 2003 server Enterprise license lists for $4k. If you're trying to break into a competitive environment and compete on price, this alone may make you uncompetitive. I have seen situations where a Windows-based solution (server, database, and custom development coupled with a content management system) is two or three times the price of an open source solution.
I know that it has been answered, but I will put my 2 cents. Why are you wondering about the cost of ASP.net? In my opinion, the choice of technology in your case (1-2 ppl development freelancer team) should be governed by technology familiarity. If you are an ASP.net expert, the expense of buying the products and MSDN subscription is well-worth it, because it's your primary language of choice that you know well, hence the projects that you implement, will be done better and faster, so it makes sense to stay with it.
However, if you happen to know another technology just as well and you are comfortable that you can deliver a robust product on-time with it, it may be worth it to go low cost. As a contractor, the main objective is to not lose time/money hence you pick a technology that balances your expenses and time spent learning it. In other words, if you are a Java expert, there is no point of paying for asp.net. If you know asp,net well already, then sure, stay with it.
The clients rarely care whether you used Ruby, PHP, Python, Java or ASP.net. They care about time lines, their cost and quality.
I find that it does not cost much money to use. It does infact cost a pretty penny to get windows based hosting. Visual studio is also expensive. After those, though, not many expenses are encountered.
If you want to use the more professional versions of Visual Studio to develop your applications: you will need to pay for that.
Also, there are a lot of commercial components available on the market. These will save you time or improve your product, but at a cost.
For open source, there are also a lot of components, but in this scene most is free/open.
My company (a large organization) is developing a "road-map" for evolving their rather old, tangled confederation of systems to an SOA model. A few people are pushing hard for using Websphere Integration Developer and Websphere Process Server as the defacto platform for developing future applications...because they feel IBM is a stable vendor, the tools are made for the enterprise, they drank the "business agility" BPEL kool-aid, etc.
Does anyone have positive or negative thoughts on this platform? Do the GUI tools help eliminate monotonous/redundant coding...or just obscure things and make things harder to maintain? Basically, do the benefits justify the complexity?
My experience with the IBM Java tool set is pure pain. Days to install lots of different versions of different components all incompatible with each other, discover a bug in component A get told to update to see if it fixes, updating component A breaks component B and C, get told to update these etc.
I find Eclipse with out the IBM extensions far more stable and quicker and provides more features (as its stable versions are a couple releases ahead of WID/RAD).
I would advise against going the IBM way for development tools. As for process server I have less experience but the people in my team using it seemed to enjoy it as much as I enjoyed WID. not a lot.
So far I havent been impressed by any tools with the "SOA" and/or "BPM" labels on them. My "roadmap" would be very very iterative to see some results with the archetecture as fast as possible while trying to grab some of the easy fruits. That way you gain your feel for what works for you and your people.
I would never let any vendor push me anywhere in the "scuplturing" of the architecture.
I agree with other users complaining about WID. The only reason we are using WID is that a decision was made a while back to use IBM products across the board by our sales department.
That's right, our sales department made the decision to use IBM products.
Development has been painful and frustrating. We have lots of stability problems with Process Server, sometimes it doesn't want to start or shutdown properly. Yeah you can easily draw processes in the IDE, but most any toolset provides that functionality these days. It is nothing special or unique to WID or IBM. IBM is a few iterations behind mainstream.
There are plenty of open source implementations out there that offer great support. Checkout JBoss or RedHat, they are pretty good. If that doesn't float your boat, you can always use Apache tools.
Walter
Developers don't choose WID, WMB, or WPS. Managers do, because IBM is a "stable vendor".
Look at JBoss, or K.I.S.S.
WID/WPS is actually pretty simple. The original intention was for analysts and business people to "compose" services (DO NOT LET THEM DO THIS!) so the UI is simple and easy.
Most of the work will be in defineing and implementing the back end services which depending on the platform will mostly involve wrapping existing code in SOA service.
The most important thing to bear in mind is that SOAP is technoligy and SOA is an architecture and a state of mind.
There is a zen to a succesful SOA implementation. Its all about "business services", if you have a service that you cannot describe to a business user in less than six words you have done it wrong! Ideally the service name alone should be enough to describe the functionality of the service.
If you end up with a service called "MyApp.GetContactData" described as "get name, addresses tel fax etc." then you are there. If You have a service called MyAppGetFaxNoFromOldSys" described as "Retrieve current-fax-nmbr from telephony table in legacy system" you are doomed!
Incidently most of the Websphere tooling for WS* is pretty nice. But I would recommend the very wonderful SAOPUI tool from http://www.eviware.com which is very good for compsing/reading WSDL based messages and also function as a useful test client or server.
Do the GUI tools help eliminate monotonous/redundant coding...or just obscure things and make things harder to maintain? Basically, do the benefits justify the complexity?
As a Developer, I find the tools at varying levels of being bug free. 6.0.1 was a pain, 6.2 is so much better. But once you develop with the tool, there is minimal effort to maintain it. I develop in hours what java developers take days to do. It is also easy to maintain as changes can be made very quickly. I cannot answer your question from the perspective of an architect or a Manager but i would agree with comments of some others here.