Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
How should an experienced .NET & SQL developer go about becoming a BizTalk expert for a project starting in 1 month? How should I spend my limited time to gain some practical skill & knowledge in BizTalk so I can "walk the talk"?
I am self employed, and would not be willing to spend more than USD300. I have the book "Professional BizTalk Server 2006" by Wrox, but have not found it to be a particularly good learning resource (very dry, needs more real world examples).
The BizTalk Virtual Labs in MSDN are a pretty good place to start with. Pluralsight also has several good BizTalk courses, and their online subscription isn't too expensive; would likely be a good option.
I agree with everything written this far. All solid info.
I have a few addons, coming from a fellow freelancer working with BizTalk since 2002:
Unit testing.
It's not easy to do, but check out BizUnit. A Codeplex based toolset written and maintained by Kevin Smith. One of the early BizTalk heroes :-) http://bizunit.codeplex.com/
Deployment / getting things into production
But also keep in mind that none of the day to day development stuff will prepare you for the part of the project where you have to deploy the app and make sure that it is "manageable" by operations. This can be quite complex, and is a topic in it's own right.
Check out Apress Pro BizTalk 2009, it's got a decent (IMO) chapter on this.
The entire development process around BizTalk.
The first two chapters of the same book will give you a good impression on what a BizTalk project is about. Where to use it, and where to not use it, how to organize projects, and name your stuff. Really a good collection of info that you would only get by reading 5-6 years of blogs back in time :-)
And one last thing. Depending on the roles on the project, you might be asked to optimize and tune BizTalk. And if they don't ask you. Make sure that you ask if others have done that, because you have to do it. BizTalk should always be tuned towards what it is supposed to do. Low latency vs high throughput, tuned according to hardware, correct setup and config of network around the SQL boxes, etc etc etc. This can be hairy stuff, and you should be careful not to jump into it before reading up on it all. But it's a subject we as freelancers are often expected to be able to deal with ... so thought I might bring it up.
Example ... BizTalk x64 processes on an x64 box runs really bad out of the box, actually worse than on the x86 processes. The 64 bit processes need to be tuned to really use all the MEM that are availble to them.
Anyways ... a bag of mixed tips and I hope you can use some of them! And good luck! It can be a tough start, but if used right, BizTalk can be a great product/toolset.
And remember .... if it is ugly, or hard, or both. You are doing it wrong. And don't be afraid to dive into .net code, and bolt it onto the BizTalk box. We all do it ... some just won't admit to it :-D
Start with the advice of tomasr.
Then, try and build something as real as possible. Biztalk is the kind of product where everything seems fine when you read the book and follow the examples, then you sit down to do something and you are thinking "what do I do now".
As per Thomas and Shiraz - set up an environment and get your hands dirty. If you haven't done so already, download and install BizTalk Server 2010 Developer Edition
But just to temper your expectation, IMHO expertise in BizTalk (or any other EAI / BPM / ESB product) can take years to accumulate.
It isn't clear whether you are developing for a client with an established BizTalk installation, or if this is the client's first BizTalk deployment. If so, one thing not to be underestimated is that the operational considerations of running a production BizTalk environment (performance, redundancy, reliability, auditing, tracking, monitoring with SCOM etc) are as complex as the development and testing - but understanding of this will be important to 'walk the talk'.
W.r.t. dev, start with some a simple EAI type mapping project, and then work your way through the SDK samples progress to some common messaging patterns (e.g. batching with aggregator), and then move into the BPM type orchestrations. You can probably leave BAM and the BRE for later.
Good luck!
+1 to tomasr for mentioning the virtual labs. Getting hands-on is definitely the way to go, as Shiraz Bhaiji also mentions. Hopefully you're not starting with BizTalk 2006, and can go with the latest: 2010. If that's the case, you can get the Developer Ed. of BizTalk 2010 for free now (see link from nonnb).
I'd also recommend Richard Seroter's book: 'SOA Patterns with BizTalk Server 2009' (available on Amazon.com). There are many ways to do the "wrong" things with BizTalk, and this book does an excellent job of walking through both the how and the why of building BizTalk solutions (with the code samples available from the publisher's site). And yes, it pretty much takes a whole book to go through it all. It's a good (more readable) companion to the Pro BizTalk 20xx series (which is generally better for very specific questions/tasks).
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 10 years ago.
What are the advantages and disadvantages of coding your own blogging engine from scratch, versus using an already existing engine (for example, but not necessarily, wordpress)?
The biggest reason for going with developed blogging applications today is
probably interoperability. Seasoned blogging applications of today include
plug-ins and fundamental development inertia that ensures that you will interface well
with things like Twitter, Flickr, and social networking sites. Only a
spectacular developer (with a lot of time) would be able to custom code a
solution for all the APIs and other bells and whistles that, in the course of a blog's lifetime, they will want to use or at least experiment with. To build a custom blogging application is to make its default state a basically isolated one. And isolation for many blogs doesn't work.
The biggest plus for using a custom blogging application anyway is that you retain a high degree of control over the application's core behavior, and, since you will likely host it on your own server, direct access to its statistical metrics. If you know well ahead of time that you will not care about interoperability beyond, say RSS, or one or 2 other channels, and have the time to invest in core development, a custom blog is a great way to maintain a look and feel that will positively startle visitors who are used to a constant WordPress or Blogspot layout. One major pitfall, it seems, is that off the shelf blogging applications require you to learn how to manipulate each of their various presentations. It's not hard if you want to simply adopt any thousands of "themes" that typically exist for them, but then, your presentation will not be unique. Sooner or later a visitor to your blog will encounter the same look and feel elsewhere, exactly. The solution there is to hire a custom developer but that of course costs $$$. Even if YOU are that developer who will wind up trading coding-for-core-functionality time, for learning and coding for presentational individuality. Expensive either way.
I am struggling with this question myself. As a proponent of "everything independent" on the web I hate the idea of giving up low level control of my blog. I've been online since the consumer web first took off and understand the ease by which a website can be created using nothing but notepad and an FTP client. To me, anything beyond these basic tools is very "AOLish", and yet, many blogging applications have now evolved into full content management frameworks that would rival the complexity of mastering that which it once took just to figure out basic HTML. I've finally taken to in-depth experimentation with some of the more popular blogging solutions (WordPress, Blogger), and am shocked to find out that after spending so much time maintaining my own solutions, how quickly (and much better) it is to compose and manage entries with them. Since most of my blogs are not profit projects, time to compose has not been a factor for me. However, this may change. If it comes down to where I need to manage and concern myself more with content than mechanics to get my messages out, I will probably swing to seasoned blogging app mode and hope I learn enough about my platform to make it truly a unique experience anyway. That would probably be the best outcome for anyone like us debating this.
Dave
I just set up my own blog and I had to answer this same question myself. Here are the main reasons I went with BlogEngine.Net
Coding the entire thing myself would have taken a long time
I saw that there were a lot of themes available (and that making/modifying themes is easy)
Why reinvent the wheel? (would you write something that the public engines don't already do?)
Advantages of writing your own
It's fun
You might learn new programming tricks or techniques
Using a software you wrote is more satisfying than using someone else's
It will be exactly as you want it
Disadvantages
It takes time
Security risks. A high profile open source engine such as Wordpress is less likely to have security vulnerabilities than your own, especially if you don't have experience in web development. (However there are many high profile programs full of vulnerabilities, such as the widely used Internet Explorer), so take this with a grain of salt.
Features. Wordpress/others will probably have more features (even though some people don't like software with too many features)
You must keep improving your engine over time. If you stop but decide to keep blogging, you will probably want to move to Wordpress, especially if some features you really want aren't implemented yet in yours. This can be problematic, especially if you didn't plan export features.
Actually I went through this path.
For fun and learning reasons I coded my own little content-management system which I used for rudimentary blogging. It had quite static content (no comments were allowed) but it was enough for me. One year later I decided to switch to wordpress and am really happy with it.
Today I would change my approach and would go for wordpress instantly.
Reasons from product perspective:
You won't be able to feature-compete with wordpress (including plugins)
You won't be able to have such a stable and secure app as wordpress
Responsive community (both documentation and patches)
Continous releases
Reasons from learning perspective:
You learn a lot by understanding and reading other's source code.
You can make the product better instead of reinventing the wheel (by providing own plugins or bug-fixes).
It is a far more realistic job-setup: You hardly build apps from scratch but rather extend, integrate and maintain them. Also you work in a team.
Nowadays I would start to build 'from-scatch' software only if:
There is no software which can suit you or you can't extend to your needs.
You need a custom software for business reasons (e.g. you are a startup with fresh ideas)
Building a new software is cheaper as maintaining/extending existing one
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.
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 10 years ago.
I am currently looking at a distributed cache solution.
If money was not an issue, which would you recommend?
www.scaleoutsoftware.com
ncache
memcacheddotnet
MS Velocity
Out of your selection I've only ever attempted to use memcached, and even then it wasn't the C#/.NET libraries.
However memcached technology is fairly well proven, just look at the sites that use it:
...The system is used by several very large, well-known sites including YouTube, LiveJournal, Slashdot, Wikipedia, SourceForge, ShowClix, GameFAQs, Facebook, Digg, Twitter, Fotolog, BoardGameGeek, NYTimes.com, deviantART, Jamendo, Kayak, VxV, ThePirateBay and Netlog.
I don't really see a reason to look at the other solution's.
Good Luck,
Brian G.
One thing that people typically forget when evaluating solutions is dedicated support.
If you go with memcached then you'll get none, because you're using completely open source software that is not backed by any vendor. Yes, the core platform is well tested by virtue of age, but the C# client libraries are probably much less so. And yes, you'll probably get some help on forums and the like, but there is no guarantee responses will be fast, and no guarantee you'll get any responses at all.
I don't know what the support for NCache or the ScaleOut cache is like, but it's something that's worth finding out before choosing them. I've dealt with many companies for support over the last few years and the support is often outsourced to people who don't even work at the company (with no chance of getting to the people who do) and this means no chance of getting quality of timely support. On the other hand I've also dealt with companies who'll escalate serious issues to the right people, fix important issues very fast, and ship you a personal patch.
One of those companies is Microsoft, which is one of the reasons that we use their software as our platform. If you have a production issue, then you can rely on their support. So my inclination would be to go with Velocity largely on this basis.
Possible the most important thing though, whichever cache you choose, is to abstract it behind your own interface (e.g. ICache) which will allow you to evaluate a number of them without holding up the rest of the development process. This means that even if your initial decision turns out not to work for you, you can switch it without breaking much of the application.
(Note: I'm assuming here that all caches have sufficient features to support what you need from them, and that all caches have sufficient and broadly similar performance. This may not be a valid assumption, in which case you'll need to provide more detail in your question as to why it isn't).
You could also add Oracle Coherence to your list. It has both .NET and Java APIs.
From microsoft : App fabric
Commerical : NCache
Open source : RIAK
We tried a couple in the end we use the SQL session provider for asp.net/mvc yes there is the overhead of the connection to the DB but our DB server is very fast and the web farm has loads of capacity so not an issue.
Very interested in RIAK has .net client and used by Yahoo - can be scaled to many manu server
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
Recently a friend of mine had gone from a high level NOC position to a developer. Before that he was just doing the help desk stuff. He has no degree, only the usual MIS/networking certifications and as far as I know only tinkers with code on the weekends. I can see where in some scenarios having a good understanding of configurations, packets, users, OU's, etc would be extremely beneficial to a developer.
My question is this, how many full time developers started off this way? Even how many people dual wield the responsibility of developer/systems administrator/network administration?
I'm sure that this is a fairly common scenario. I've spent 12 years in I.T. and I find that as time goes on, the real income comes from being a specialist (DBA, coder, etc.) as opposed to a generalist (network admin, helpdesk).
It's actually the path that my career is taking. I'm not quite a full-time DBA or developer but that's where I'm heading.
I'm also willing to bet that the people skills I've picked up along the way (helpdesk support, network admin, systems analyst) will help me in my DBA/Developer career. Skills I don't feel I would have gotten had I jumped right in to a coding career.
Indeed. I think developers should know the platform they are building software for. If a dev has worked as sysadmin before, he will know how to integreate his software well. Some Windows-Desktop-App related "integration smells" that come to my mind:
App does not run unter normal-user privileges (run on properly secured enterprise desktops? oops!)
App requires write permissions to all kind of system folders (security? oops!)
App stores user settings in 'nonstandard' locations like %programfiles% (backup? permissions? oops!)
App does not provide silent-installable setups (deployment? oops!)
Etc..
A real sysadmin would never write software that has one of the above integration smells. Really.
It's quite common in small companies. I did that for some time - developing the software we sold to customers, keeping the network going, and adding features to the database as needed for a manufacturing company of fewer than 20 people.
You wear many hats in a small business.
But I started off programming microcontrollers in high school, so I can't claim this is where I started.
It is very helpful to have a working knowledge of all these systems as a developer.
-Adam
The overlap of developers and admins happens quite a bit. Our last admin developed on the side just so he'd have a better understanding of what he was helping support. When he left I became the admin just because I tinkered with admin stuff on the side to know how my software was being supported.
A broad understanding with a few focuses is what I'd say is best for any technical professional. Then with a bit of study you can change to meet whatever need may arise.
I've seen it more the other way where a programmer also "admins" the servers and sometimes network. I've definitely been in that position.
I would think it can easily go the other way as well where an admin can start programming systems, but from my experience it's not as common. Whenever I ask a server admin or network person "do you program too?" most of the time the answer is "no".
I think it might be easier for programmers to cross the line because when you are programming a system unless you always have an admin available you need to be able to set up your own environment and that usually includes setting up a server.
I started off as a NOC operator, eventually working my way up to a senior network engineer position. During the last 2-3 years of my tenure at my previous company, I picked up a fondness for programming and started teaching myself everything I could on my own time. Around 2005, I left said company for a small startup and still work there today as as the admin and primary developer.
The one challenge I impose upon myself is to not make admin changes at the drop of a hat to satisfy programming challenges. I must force myself to code in a way that any application I make can be redeployed elsewhere with minimal privileges, despite the fact that I can do pretty much anything I want with our own servers. It's a fine line between performing both duties well and performing one duty badly due to the needs of the other.
I'm here.
Although I've been tinkering with code since I was a child, my first full-time job was being a system administrator, a DBA and other related roles.
Afterwards I worked full time job as a developer, and now I'm both a developer and a security researcher.
Also, I managed to complete M.Sc in CS.
I believe that such transitions are possible, and very beneficial, as you get a wider view on your field of work.