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 10 years ago.
Improve this question
I am a Asp.Net developer, currently working on Webforms in 3.5. I do C# now, used to do VB.Net. I am also a middle tier developer (business layer and data layer) working on refactoring the current code base to use the Service-Repository pattern.
My boss asked me if I would like to start doing Sharepoint development (company is currently upgrading to 2010, so I would assume I would be doing 2010).
I have read on here that it takes a long time to get up to speed with Sharepoint development, and I don't want to be thrown into the fire while still learning and not knowing what I am doing.
Also, any good places to start learning? I told my boss I would look into it for about a week and get back to them.
Some good links:
Get Started on developing on
SharePoint 2010
SharePoint 2010 Advanced Developer
Training
SharePoint Hands on lab
SharePoint Developer Center
SharePoint Foundation Development in
Depth
Good luck to you
I'd recommend finding out what they anticipate the company's needs are and whether they anticipate that this will become your primary role. Ask about what projects they have in mind. (Of course they're going to say a small percentage, and no, you'll be expected to continue with your regular duties...)
It may be helpful to schedule a 'state of the union' meeting a couple months out to realistically assess how much of your life Sharepoint has taken over, and whether someone else should be brought in to help (or take over).
It certainly can't hurt to get another set of skills under your belt. Having the background that you do will certainly help you be competitive. If you don't like the work, there's nothing saying that you have to include it in future resumes...
Don't be scared to learn SharePoint. It may seem like a difficult task at first, but if you take it one step at a time you should be ok. In fact, SharePoint is just a (really big) asp.net web application, so all your existing skills come in handy.
Also the fact that MS finally put some good quality project templates for SharePoint development in Visual Studio 2010 makes the learning curve less steep.
There are also some good books available to get you started. If the company wants you to learn SharePoint, I suppose they would be happy to pay the bill for those. :-)
Yes, SharePoint development has a steam learning curve, but from what you already do, you're half way there.
The best place to start is here:
http://channel9.msdn.com/learn/courses/SharePoint2010Developer/
I agree with the answers above. Only thing I would add is, if you had to learn SharePoint, starting with the 2010 version such an advantage over 2007. Especially when you add in Visual Studio 2010...
Regarding where to start, can't hurt learning from the horse's mouth (i.e Microsoft's MSDN sites). Also, be sure to request that your company get you adequate hands-on developer training.
It might be helpful to know that SharePoint.SE is dedicated to only SharePoint questions. If you have a non-programming related SharePoint question, or even a programming one, that is a good site to use.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I've been given a project at my job involving SharePoint. I'm eventually supposed to replace our current Intranet site and and website using SharePoint.
I've never used SharePoint before and was wondering where a good place to start would be. I also have little knowledge of website design in the first place. Can anyone reccomend a book or a detailed site that will explain things to me like I'm an idiot?
It's always hard suggesting beginner's books because you never know where to start.
Sharepoint, as with all software, is best learned by playing with it. You said you are supposed to replace your current intranet site with Sharepoint. The best thing you can do right now is set up a little test environment with Sharepoint. I say "a little" because in the end it is not that hard, but looking at the documentation from Microsoft: Setting Up the Development Environment for SharePoint 2010 on Windows Vista, Windows 7, and Windows Server 2008, it is hard ;-)
Microsoft also offers the 2010 Information Worker Demonstration and Evaluation Virtual Machine (RTM) - a whopping 3GB download (you only need 2010-7a). Mind you: this Virtual machine only runs under Windows Server 2008 R2 with Hyper-V activated, so not on your standard issue Windows XP.
Talking of which: Sharepoint 2010 needs a 64 Bit System (go with Windows Server 2008 to make yourself happy) and at least 8GB of RAM.
That being said of some test system you can play with (create some document libraries, look at workflows, get yourself accustomed to master pages etc.) there are of course some theoretical books. You asked about explain things to me like I'm an idiot?, lucky you: Amazon's choice of Sharepoint 2010 for Dummies books. If you know the "for Dummies" series - the books are not very in depth, but they are o.k. at giving a general picture.
If you want more professional books, there is SharePoint 2010 User's Guide: Learning Microsoft's Business Collaboration Platform or Beginning SharePoint 2010 Development (Wrox Beginning Guides).
Btw: The best tool to start your customization efforts, once you have your test environment is Microsoft's Sharepoint Designer 2010. It's a breeze creating custom master pages or changing some CSS quickly.
The first tasks I would set for myself after understanding a bit of Sharepoint: Customize a standard Sharepoint Site (Team Site, Publishing, ...) to match my companies appearance. Some hints: Look at Themes, Master Pages, Layouts.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
We have been looking to implement Agile methodology within our geographically distributed development team, so i need suggestions on any free on-line application that you have used and find useful.
Right now we are using paper cards and wall to manage this :), but we want to shift to an on-line version preferably free.
I have used TargetProcess at my previous job!
My Core requirements are:
Business Analyst can add user stories
We can assign, prioritize different user stories to developers.
QA team can add test cases around different user stories.
Project Manager can track the time of all the resources and can pull reports for upper management
I've been using Pivotal Tracker which is a free agile project management tool and covers the following agile concepts:
Velocity tracking and emergent iterations
Story-based iterative planning
Real-time collaboration
Would certainly recommend you try this before paying for an alternative.
Also, as mentioned, Basecamp is a great tool for maintaining documentation, to-do lists and the rest. There is a barely promoted free option for single project use that you will find on the signup page below the Max and Premium options.
Possibly not an agile tool as such (depends on your definition) but the free Team City continuous integration and build server is the kind of software that you don't believe you could live without once you've used it. Basically a commit to SVN by any developer triggers a build to your staging server about 30 seconds later meaning the latest build is very agile!
Timetracking: slimtimer.com.
This is one of the best time trackers I've seen (and I've seen many)
Mercurial code hosting: list available here.
I've only used the service provided by sourceforge.net and was satisfied with it.
Web conferencing, desktop and whiteboard sharing: Dimdim.
I haven't had much luck with it, but I believe it might perform much better on a Windows machine.
All sorts of version control, wiki, RSS feeds: sourceforge.net.
It's only for FOSS projects, though, but it really ofers a lot of services.
Other than that, basecamp should fit right in an agile process (although I haven't used it much) with a reasonable price ($50/month...)
Try using http://www.icescrum.org/en/. This is open source tool and free platform for Agile developments. You can read its feature on Features tab on website.
Also, Visit http://www.openlogic.com/wazi/bid/188152/Comparing-Open-Source-Agile-Project-Management-Tools. This article compares the most compelling open source options.
At work we use a product called Skinnyboard. It has a ton of great features, like:
Support for Sprints and Product Backlogs
Sprint tracking via stories/tasks
Individual task history
Sprint/Product Backlog burndown, to see projected finish dates, etc.
It's free to try, which gives you (I believe) one board. After that you have to pay though, but it's a great product and definitely worth it.
It's simple, visually appealing, and only has what you need. In my opinion, it's like the Basecamp of SCRUM tools.
They say it better than I ever could,
AgileFant is an open source tool
for managing agile software
development activities, such as:
projects, products, releases,
iterations and backlogs. It brings
together the perspectives of long-term
product and release planning and
project portfolio management.
Another one that's recently sparked some interest and seems potentially useful (I'm in beta, easy to get in afaik) is Flowdock which is basically a mish-mash of email alerts, RSS feeds, ticketing systems and plain ol' realtime chat with status messages et al. Think of it as Google Wave that doesn't suck and check out the intro video from the front page.
Try out Flying Donut. It is a new online product inspired by scrum. You may host public or private projects.
Disclaimer: I have been using it for many months, since I helped building it, and I love it.
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 8 years ago.
Improve this question
I know this is an odd question but I need to ask it to get information to present to a client. Their lead network admin wants me to work on 30 day trial servers like Sharepoint & SQL Server to develop projects for their clients. While I will do as they ask, I'm not convinced this is the best way to go about developing software or troubleshooting previously developed software. To be honest, I've never worked on custom development for any server/software using a trial version.
What arguements are there for and against working on trial software/servers?
Pro: It enables you to mock up a concept and see if it seems like the development path will be easy before you shell out large amounts of money for the real deal.
Cons: It could trap you in a vicious cycle of wiping your virtual machine and re-installing the OS, the trial version, and your product (you do use source control, correct?) if they are hoping that this will alleviate the need for ever paying for the real product.
Suggestion: If you don't mind unsolicited advice, then I would determine why the lead admin wants to use the trial versions -- and then go from there. Until you know the reasons you cannot respond to them.
If they are doing it for the pro reason, then determine if you feel comfortable working with the possibility of switching technologies 30 days into your build. (Can you do it efficiently?)
If they are doing it to avoid spending money, present some of the alternate open source / free options that you are comfortable developing with. If they will not change their modus operandi at that point, then do what is necessary, knowing what you will be walking away from / getting in to.
(And if you don't mind one more bit of unsolicited advice -- if they are doing it for the con reason and will not change WALK AWAY)
Point them at BizSpark. Microsoft is begging people to use their stuff. A hunny will get you everything on the map for 3 years or until you start making money.
Oh, to answer your question: If I need to get funding for technology not present in the infrastructure or to do a proof of concept I would not think twice about using evals. That is what they are for. I would be evaluating the suitability of the product for use with my designs. Seems easy to me. Maybe I am just, hold on, i have to give my parrot a cracker... ;-)
Apart from the ethical arguments, there are practical ones:
What are you supposed to do if development overruns? Start reinstalling everything, wasting several days doing so?
Additionally, if the client is so strapped for cash that they want to do this, how can you be certain they will pay you (either due to cash flow problems, or simply because of their shady ethics)?
I'm pretty sure that that kind of use is a violation of license terms. Trial editions of servers are for evaluating a product. And if you are in fact creating a product, then you have gone way beyond evaluation.
I would never work under such terms. If you are developing a concrete product, get proper licenses for the development tools. I know that the developer edition of SQL server is not hugely expensive (compared to a version licensed for production use), so I would imagine that the same counts for Sharepoint.
And then there is of course, as already mentioned, what do you do when the trail period expires?
I wouldn't mind doing this so long as the job is shorter than 30 days. Make sure your work contract they're paying for the time worked and not specific deliverables, because your deliverables are time-bombed.
Also be prepared to walk away. If this company doesn't have resources to get the right software, you don't want to be there longer than 30 days anyhow.
Microsoft provides several pre-built virtual machines, that contains full stacks.
(Server 2008/Sql 2008/Sharepoin) (Server 2003/Sql/Project Server) etc.
They are time bombed, but often (not always) Microsoft will provide a new image after the time out.
The benefit of using these images is that they are already configured and good to go.
As an example here is a beta of sharepoint 2010 (http://www.microsoft.com/downloads/details.aspx?FamilyID=0c51819b-3d40-435c-a103-a5481fe0a0d2&displaylang=en).
If the project has a quick timeline, it provides the developers access to the configured stack right away, with no ramp up time of building new virtual machines.
Esp when working on beta/early release software this is great.
The SQL Server evaluation's download page mentions that the evaluation license is good for 180 days, and specifically advertises it as a tool you can use for mission-critical applications. This tells me MS is fine with your using it for development work.
To answer a question with more questions:
How long does this project run?
What phase of the effort are you in now?
Is this an internal/proof-of-concept project, or something that your customer(s) will be using for a long time?
If you are going to need to use SQL Server for Operations & Maintenance support months past the initial evaluation period, you ought to get a license for the full version of it. And also consider what your customers are using so that you can reproduce any bugs that come back from them.
I don't think it's ethical to continually renew evaluation licenses to have a longer evaluation period. Companies call them "evaluations" as a try-before-you-buy, not a keep-trying-without-buying.
I'm not sure what others are seeing as unethical here. If the project is short enough to be completed within the 30 day trial, I don't see any issues. I think that's a great use of trials - if they can't handle a clients applications then they aren't a good option and you can use something else.
I think others here have given some good advice regarding the longer than 30 days projects and some good contract ideas.
How in-house do the servers have to be? Would a hosted solution work for them? (Dreamhost, Amazon Web Services, whatever)? Some hosting systems provide pretty complex machine images (lots of stuff pre-installed--definitely AWS, presumably most others), decreasing setup time/effort. I think those come with licenses, though I don't honestly know. Plus, in at least some cases, you (they) only pay for what you (they) use.
Obviously no good if the physical machine needs to be in-house, or if things are otherwise super-sensitive.
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 5 years ago.
Improve this question
Right now, our teams are using a combination of a bulletin board and an excel spreadsheet to keep track of tasks and to draw a burndown chart. Backlogs are keep on index cards in envelopes.
This works well when the stakeholders are in the same location. However, we will soon have Scrum teams in two geographically distant locations and I am looking for best practices on how we can leverage Sharepoint to help us communicate around Scrum artifacts (backlog, burndown chart, velocity, etc.).
How did you leverage Sharepoint for that purpose, what are the best practices and the potential pitfalls?
We actually use Sharepoint for our Agile development and have found it works pretty well for project management/collaboration.
There are 2 things we do which I found particularly useful, metrics tracking and automated testing. We use the document library and infopath to add all of our stories for the project to the site. The infopath form should contain all the information you need for a story: points, estimated time, developer, tester, story tasks, test cases.
For metrics, we create web parts for: burn down charts, velocity, points per iteration, etc.
This is especially nice for Managers or customers to see that progress being made on the project and will help them make decisions regarding features vs. release time.
For testing we have a simple SEND-RECV-ASSERT language which runs the tests nightly by scraping the XML for automated tests. The we have a little Green/Red webpart on the main page which tells you the stat of the tests.
This can be done pretty simply with some XML parsing since the backend of the document library is XML. (We currently use some simple ActiveX and javascript)
The metrics are pretty easy to set up (just some xml parsing and html charting). The automated testing takes some time to set up a test runner, but once its in place, and easy enough, you can even have customers/managers write acceptance tests! Agile! :)
If you have SharePoint in house already,along with a user base that is comfortable using it I think it would be fairly easy to get started with using it for SCRUM. I would start with the following:
A site collection to hold 1 scrum site per project
A scrum site should contain:
Document library for the electronic files (add columns for categorization as appropriate)
List of team members
Discussion board
The site can be built from a Wiki site template if its necessary.
Once you get the scrum site "feeling right" save it as a template so its easy to spin up a new one.
This solution may not be designed for SCRUM to the nth degree, but it should be enough to get you started. It seems a lot easier than having the entire team learn a new tool when it sounds like you are undergoing some other pretty radical changes.
my $0.02
jt
You really should consider something like Trello, VersionOne, Rally, or even Basecamp for this. They all have hosted solutions and offer free community versions that you can try out to get started. My experience with SharePoint is that it takes a lot of resources to maintain. If you were using Team System and had a lot of the stuff pre-built for you, that might be different -- although I have Team System and still choose to use a Wiki for my project management tasks. If you already have an investment in SharePoint as an intranet and all of the support staff, then it might be a viable solution in that case, too.
SharePoint is not the tool I would think of first for agile development. YMMV.
You need to try and keep the tool from getting in the way of working. In an ideal world the team will all be sat in a single room with big white boards, however often this is not the case and teams are distributed, or theres a push for some form of backup for the post-its.
I'm a big SharePoint fan and where you have this in house already, your already doing collaboration and team work on the platform. Adding another tool, with unique login's can work but the team need to really want to use them.
I've tried getting SharePoint out of the box to do what I wanted but it fell short. I've tried using Version One (on a number of occasions over many years, with many teams) but I find the tool is too much, there are too many otpions and things that need to be done that it gets in the way - it is a long way from the Whiteboard.
So I decided to develop what I needed for my projects. I needed a simple tool, and using the 37signals (creators of basecamp) approach I needed something with less features than the competition.
21Scrum is a simple scrum tool built on SharePoint that uses the platform, add the things that you need (white board, burndown charts) and leave you to get on with the project.
Perhaps this may be the best option for people who already have and use SharePoint - at least thats the goal.
We've setup a SharePoint workspace with lists for Release/Sprint planning, Product Backlog and Sprint Backlog.
Central element is this Task Board for SharePoint - we can drag & drop stories and tasks - even if we are not at the same location.
http://www.youtube.com/watch?v=XW89M0C3N7Q
A burndown report visualises the progress automatically.
Works great!
AFAIK, Sharepoint is ASP.net with free goodies. It is not designed for agile project management.. so you'd have to roll your own site.
IMHO instead of trying to bend the job to the tool you have.. switching to a better tool for the job would be a better option. Check this thread out to see if there is something more lightweight that fits your bill.
Also personally I'm a big fan of not digitizing the development activities.. So I'd use a spreadsheet for the backlog and post its and Big Visible charts. Use a digicam to persist diagram/design discussion snapshots (google whiteboard photo for tools) or for reports. I find that most of the "project management" tools are just excuses for generating instant status updates.. it gets in the way of software development (which is the main goal) and inhibits social interaction way too often.
(disclaimer: absolutely 0 experience with sharepoint.. except what I've read in the last 2 days so may be totally off track)
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 9 years ago.
Improve this question
Have any of you ever tried to run from sharepoint? I've worked with sharepoint enough to know that it is not something that interests me. My interests are more along the lines of APIs / backend / distributed development. Have any of you found ways, as consultants, to move away from sharepoint and keep learning other things of interest? I'm currently in a position where sharepoint is in huge demand and I can't quite find a way to simply step aside from it. any suggestions ?
If I infer correctly that you work for a consulting firm then find out what other kinds of things your firm works on. Learn those technologies better that the people who currently work on them for your firm, involve yourself in those projects, even if just in a hallway conversation manner, and come up with better (faster, cheaper) solutions for the problems your firm is solving.
Your options are really seem to be 3-fold
convince your boss your talents
would be better used elsewhere
convince your co-workers they want
you on those other teams
convince your company's clients that
they want you, specifically.
Learn Java, or Ruby.
The Microsoft sales model of "attach" whereby they sell a solution comprised of multiple technologies and then sell the next solution on the basis of "well you have already invested in SharePoint so you already have the skills in place and the infrastructure for this new bit of technology we have" is here to stay... it's very successful.
SharePoint is cloud computing for business who have MS shops... you avoid it by not doing C#. If you're doing C# then given enough time, your apps will need to run in the corporate cloud and you should be looking after your career by embracing it.
Just my 2p. Sorry if it's not quite the answer you wanted.
I know exactly what you mean. I think you don't mind the idea behind a product like SharePoint, but really hate the way its been implemented and how problematic it is. I know its a nightmare to work with.
As a C# developer, I cringe when I hear the SharePoint word, SharePoint is Lord Voldemort. But unfortunately it comes with the job of being a senior C# / Microsoft developer.
I say unfortunately because its likely if you're working in a corporate structure sooner or later you will end up having SharePoint in your solution. Not because its good, but because as others have said - MS use SharePoint as a Trojan horse to get and keep business.
There might be some hope with the new version of SharePoint coming out (2010). Maybe this will finally include a better programming / implementation model.
Otherwise either work for smaller companies (usually less pay, but not always), or try to play down your skills as a MOSS developer if possible. Never actively market them unless your salary depends on it. Remove the skill from your skill matrix, and turn down jobs that completely focus on MOSS. Some MOSS integration here and there you can live with. An entire solution focused on MOSS will drive you insane.
If all else fails, learn other non Microsoft languages, and within a year or 2, SharePoint will be but a faded memory.
I know lots of developers who are thinking about quitting IT because of SharePoint. I would say don't let it be the end of your career.
And finally bitch and moan, and inform managers on a weekly / daily basis, as to why you are battling in SharePoint. Let them know, and constantly remind them how bad a technology it is.
When life deals you lemons. Make Lemonade.
Seriously, if you are seeing SharePoint in such high demand, maybe working with the beast is the best idea. SharePoint is really just middle-ware. SharePoint can simply be a distribution point for your solutions (i.e., a user interface such as a web application can be hosted on SharePoint through a Web Content part). If you look at it, SharePoint may even prove useful as a document respository or small scale data store, in the form of lists.
Maybe you should turn down SharePoint contracts and accept contracts that interest you.
Depending on the market you are in you can simply tell your boss at the consulting company you work for that your not interested in doing Sharepoint projects anymore and that you'll be forced to look elsewhere if they continue putting you on Sharepoint projects. That would work around West Michigan where the developer demand is high and the supply is sub-par.
I'm, on the other hand, just starting to use SharePoint to enreach my currently boring C#-only projects. I'm starting to use it as a front-end to the distributed and complicated systems: simple configuration and customization, reporting, management, system control - looks like all this is available in this package it it's easy to make is usable by non-techies and by beginners.
I personally don't want to work with SharePoint anymore. I've worked on developing a solution for it and even went full charge with a web integration of it. I hated it.
First you have to master the awful programming model then handle all the deployments and it's not even the beginning. If you are developing a product for SharePoint, you have to debug the software itself which is a feat on it's own.
My solution to this is to be very upfront about it. I don't mind doing knowledge transfer and helping out people but I don't want to be developing/deploying SharePoint applications.
My boss get it, my friends get it.
Our latest joke come from someone who said a few months ago that it was "easy and fast to deploy application with SharePoint". The joke? "Did he just put easy/fast in the same sentence as SharePoint?"
So unless you salary would be lower because of it... downplay your skills on it and be upfront to your boss. :)
Have you ever looked at Alfresco (http://alfresco.com)?
It serves many of the same purposes as SharePoint, but does it from an Open Source J2EE application. It will leverage your existing collaboration / content management experience and expose you to a whole bunch of open source technologies.
Full disclosure: I work for Alfresco.
I've already given this suggestion to another guy...Running from SharePoint won't be difficult because technologies are similar to each other according to their structure. SharePoint is not the worst technology to be used, although it is limited in some way... Fortunately, software sphere is too wide to be afraid of not finding anything you can be interested in.