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.
This is really a question for the 7400 people (!) at the SharePoint Conference 2009. Of all the new features and improvements in SharePoint 2010, which one (or area or feature set) do you think will have the biggest impact on the world of SharePoint development?
I haven't had a chance to do anything with it yet, but the new BDC (Business Data Catalog), the BCS (Business Connectivity Services), looks really promising - and something that people may actually use as more than a last resort this time around.
Edit: Now that I have had the time to play with the BCS - I can tell you that it is a HUGE improvement over the BDC in terms of both flexibility and ease of use - it is going to be the center of a ton of big-business custom development work to come.
Development support on Win 7 / WS08R2
You no longer have to do your development on Windows Server. You can use Win 7, Vista, or WS08R2.
It may sound stupid, but I would say sound compatibility with Firefox is the comforting thing to know. It not because I am a big fan of Firefox, but it shows a big step of MS towards openness.
For me? The fact that I can now publish my access applications to the web. Here is a video of me playing with ms-access, and about half way through this short demo I switch over to running the application in a browser. I tested this in FireFox, and it also runs 100% perfect...
http://www.youtube.com/watch?v=AU4mH0jPntI
I liked the BDC but was disappointed at the lack of tools to quickly bring an existing SPList from another site or site collection in as a external list. It can be done, but it is a very manual tedious process. I would have liked to see a point and proxy sort of API.
Having lived through some SharePoint application upgrade disasters, I would say that I am very favorable to the new Feature Versioning and Feature Upgrade capabilities. The ability to define an upgrade path for content types and lists as well as move existing file URL's is great. With the new event and FeatureUpgrading method on the SPFeatureReceiver you can do just about anything in upgrade.
More on the Feature Upgrade...
I have been playing with Business Conectivity Services and i'm very impressed. this is the tool that will make sharepoint the bridge in a business.
Out of the box Global Navigation Components no longer use tables. I know it's really not way up there on the list of improvements, but I was super excited when I read this.
SharePoint 2010 Changes in Rendering
2 biggest improvements:
1 - Dev tools support - You can throw away WSPBuilder, SharePoint Manager, and all the other hodge-podge tools you used to develop SharePoint Solutions.
2 - Taxonomy/MetaData - You can add a metadata column to any content type and query that information accross farms. Leverages the new service application infrastructure which gets rid of SSP's
Related
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 9 years ago.
I think this one might get shut down, but hopefully I can get some meaningful responses if it does.
My employer is about to upgrade our WSS 3.0 Intranet site with SharePoint 2013 Standard. I have trawled Stack Overflow for SharePoint positives and negatives and I must admit that I saw a LOT of people negative towards it because it is needlessly complicated to work with and modify. Many of these were related to 2007 though, but I still saw them with 2010.
Are there many people who have used 2013 in a production environment and have feedback about how the product has grown over the past few iterations as far as front end usability and back end expandability goes? Is SharePoint's current version ready for the average business who do not have teams of developers to modify it?
First, decide if you really need all that sharepoint has to offer beyond the ability to store and retrieve documents on a central server.
If you need any of the following:
Create online applications, self-serve forms.
Use it as your company intranet.
Integration with anything that is not an Office product or .NET friendly.
Then you will need specialized support - or at least dedicate a person to train and develop on it. Also consider the cost implications of supporting it in the long term; check with your organization if they have an enterprise agreement which will help offset some of the costs.
The best option if you want to use sharepoint is to have Microsoft run it for you. This way you can do a fair evaluation before you decide to commit to it.
From a usability perspective - it is by far the most user friendly thanks to it built-in integration with Office. This is perhaps its best killer feature, and one that every sharepoint competitor tries to emulate.
The web interface was also greatly improved in 2013, however keep in mind that most of the features are Internet Explorer 8+ specific. This might run afoul of your corporate policies.
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 a recent graduate and got a job as a junior SharePoint developer few months ago. For the last few months, I have been working on SharePoint development, e.g. webparts, .Net Forms, K2, Lists, Features, for Moss and a little bit for SharePoint 2010 as well...
Now because I made a future plan to become a SharePoint architect, I am not sure what way I need to follow to become what I want to, As there are so many things to learn in SharePoint, I am looking for Book or a series of Book that will help me gain knowledge as a SharePoint Architect has.
I am a bit confused with SharePoint architecture as well, like If I want to develop a new SharePoint Solution, What hardware e.g. Servers, Do I need + Software, e.g. We use .Net Forms, but are they better then using Info-Path forms ?
Thanks (I know its not a Coding question but I think its somehow related to Programming so please dont close it.. Cheers)
There is a huge amount to learn in order to "become" an architect for SharePoint. Do not forget that you will need to learn how the SharePoint content database works, especially how documents are stored. You will also need to figure out the infrastructure part of the equation, especially how virtualised environments will affect server performance.
Essentially, there is not enough space to list all the books that could be useful.
You have set yourself a long term task, so go hard with the curiosity. Whenever you run across a subject that you do not know the details of, hit google and find out.
For example, the difference between .NET forms and Info path forms maybe available in a book, but you are going to learn more quickly and thoroughly by creating some Infopath forms and having a look at how both are implemented.
There is no real shortcut around the hard graft required to learn SharePoint (except perhaps finding someone who already is good at this and learning from them directly).
A free ebook downlodable from msdn :
Developing Applications for SharePoint 2010
http://msdn.microsoft.com/en-us/library/ff770300.aspx
It's a good starting point.
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 12 years ago.
I'm building a web app and starting to feel the pain developing slick UI features -- I tried iPhone/Android programming and it's so damn simple. Why is it that everyone still settles for the hacked-together tools that comprise web programming, instead of gravitating towards RIAs?
I want to program the app with an RIA but...the most popular websites are suspiciously not using them.
Thanks!
There's a couple of drawbacks to RIA... I'm mostly speaking to Flash/Silverlight and the like, as Ajax RIA is a bit different. The drawbacks:
Vendor lockin... once you develop a platform using RIA you are locked into whichever vendor supports the RIA. You are at the mercy of their support, upgrade paths, etc. Using standard web technologies you won't fall into this.
Search engine indexing... Search indexing of RIA is relatively new, so there might be issues getting your content known.
Performance/interoperability issues... Everyone knows about Apple's rejection of Flash. Writing your web application adhering to the standards guarantees your application is accessible to any standards compliant browser. A company like Apple can't just pull the plug on you.
Accessibility issues... It might not be as easy to program for 508 compliance using Flash/Silverlight as it would be with plain-old HTML. 508 compliance is a must for any big website.
You mentioned phones... (Android/iOS) Obviously people don't target mobile phones using Flash/Silverlight for the aforementioned reasons. For phones, generally it makes more sense to create a mobile application as you get more native features then you would if you were creating a mobile website. However, creating a mobile website requires you to write your application once whereas you would need to write your application for each phone you wish to target if you went the mobile application route.
Flex feels slow and non-native.
RIAs running on the desktop generally have to feel native on at least two very different operating systems. You then have to deal with issues on the users machine and the whole nightmare of versioning and upgrades. Web apps only have to work on your server configuration.
RIAs running in the browser feel even slower because all that slickness has to be transferred to the client. They also break the way people expect websites to work.
They are useful for some applications, but normal HTML/JS/AJAX serves most web applications better.
Phones are a different environment entirely and make more sense for the RIA model in many ways.
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 have noticed some developers picking up new skills and moving from one platform to the other? How do they do it? How do they justify for the lack of experience in the said platform they get the job?
Is it based on relevance to their previous experience? do they get certified in the target platform and work at a junior level accepting a pay cut? is it simpler if you are into contracting/consulting? Or is it simply a matter of projecting the resume correctly?
Actually, a lot of seemingly different platforms are really very similar, if you understand what goes on "under the hood," as it were. Though I've barely touched a Microsoft platform for well over a decade, for example, I have little difficulty developing things there because deep knowledge of computer systems in general is quite transferable.
For me, moving from LAMP to .Net was a work necessity. The consulting company I work for needed a PHP guy right away which is how I got in, but that project completed abruptly and they did not have an PHP work on the horizon.
In the closing weeks of the PHP project, I took an online O'Reilly course in C# and worked closely with a more experienced developer on a Windows application for the same client. Once the PHP gig completed I was able to start right away on a .Net project and I've had .Net clients ever since.
The key for me was flexibility. I let my employer know immediately that I was interested in different technologies and platforms and have taken the initiative by requesting access to courses and taking advantage of our yearly book allowance to explore different areas. When opportunities arise for investigating new directions like Mobility (PDAs, specialty devices and tablets) I jumped at the chance.
If your employer doesn't have policies which promote this type of self-directed expansion, then try to build a type of application you are familiar with in a new platform. Once you have you have a decent grasp of the tech, get involved with open source projects in your target platform and look for paid outside opportunities (i.e. Craigslist, elance, etc.) while you are still learning.
Most likely it is a result of circumstances. In these touch economic times being able to move outside your comfort zones is crucial
I really haven't seen a lot of reluctance on anybody's part to put developers on platforms that are new to them. Changes in computer language tend to be far more worrisome to managers than platform changes.
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.
Our group is currently reviewing our toolset and looking for new defect/issue tracking software in additional to source control, and project management software.
For issue tracking, we've looked at bugzilla, fogbugz, bugtracker.net, sourcegear fortres, and bugnet.
I'm not satisfied with the list we've come up with, so I'm curios to know what others are using.
We're looking for Active directory integration for security, although we'd settle for a windows app, a web interface may be preferential, visual studio integration is also a bonus. We need to prioritize defects, mark the version the defect was found in, mark the version the defect was fixed in, and hopefully be able to maintain a discussion around each issue/defect. We'd also like to categorize items as defect, enhancement request, etc. and document workarounds for defects.
Very similar question:
https://stackoverflow.com/questions/101774/what-is-your-bug-task-tracking-tool
Try Unfuddle. If you use their version control hosting (SVN and Git options) with their issue tracker, you get some good integration stuff going on. For example, you can enter a note in your commit message such as "fixes #384: Too much foo in the bar"*, and you not only get that turned into a hyperlink to the issue, but it also marks the ticket as fixed with a link back to the changeset. All good stuff. This is a web-based solution that is hosted by Unfuddle themselves, in a SaaS-type fashion.
Other than that, +1 for Trac which I've used in the past and like very much. It's quite an immature project feature-wise, although it's got a very healthy community around it that has developed plug-ins to do a lot of extra stuff (like the AD authentication you wanted). It also has similar integration with a number of source control systems, but it's much less feature-rich than the Unfuddle stuff. That is to say, you get to use an extended wiki syntax in your commit messages which is parsed by Trac when it's display to create links. It doesn't do any of the two-way stuff that Unfuddle does. Trac is available to host in-house; alternatively, if you want it hosted, there's a list of places that will do so on Trac's wiki.
*I can't remember the exact format off the top of my head.
On our current project, we've amazingly used 6 different tracking tools (2 versions of PVCS), mostly commercial. Here's my opinion on the ones that we've used. I've listed them in order of my most favored to least.
Serena Teamtrack - We use a web client. The interface is intuitive. Performance will vary across installations, but comparing with our same data in each tool, this works the fastest. It also works in Firefox.
HP Quality Center - This is also web based, but it is IE only. On the upside, it's well organized, easy to use, and full-featured. It has reasonable performance for us as well.
It has an odd feature where there isn't a save button. It saves automatically for you. To force a save, you have to navigate to another ticket. Also when you first use it, it has to install so many DLLs that it is practically a thick client. That being the case, IE sometimes gets locked up (usually when trying to reinitialize a session after session expiration). Once locked up, you occasionally have to kill IE to regain control.
Bugzilla - I didn't use this as thoroughly as the other tools, so this isn't a fair comparison. We used it briefly for some internal tickets. I suppose the big upside is the (lack of) cost. IMO, I just didn't find the interface as nice and easy to use as the other tools. Its been awhile so I apologize for lack of specifics for why I'm relegating it below the others.
Siebel - There wasn't much to like about their defect tracking tool apart from that it is better than PVCS. The interface seems hokey. It's as if the Siebel interface has a set of user interface controls and it tries to force all square pegs into its round holes. Another downside is that it uses lengthy generated IDs so its hard to reference them or search by them. Along with that, the ticket IDs aren't sequenced.
Merant PVCS - We had separate databases and used both the web client and thick client. Its been awhile now, so the details are fading. I recall there were bugs in the tool and they weren't getting fixed, for instance reports couldn't display certain fields. Performance was bad. It took a long time to load. It was slow to navigate through tickets.
Issue tracking for support is a different problem from tracking issues during development.
Trac http://trac.edgewall.org/ is a very capable tool which supports a number of large open source projects. You can find Trac hosting at places like http://www.wush.net
If you need more workflow and custom security, you'll want to look at JIRA which is from Atlassian http://www.atlassian.com. Atlassian has a number of products which you might also find useful.
For Issue tracking in a support setting, try RT http://bestpractical.com/rt. RT is deceptively simple, but I've seen it used in the largest environments and it does a good job making sure you are accountable to every you make a support commitment to.
An off-site (www) hosted solution with all the features you mentioned is NetResults Tracker
We use bugzilla, it suits us perfectly. We haven't investigated too many others because honestly it does everything we need and then some.
We don't use Visual Studio so I can't speak for integration compatibility.
Try out HappyFox ( http://www.happyfox.com), an issue and bug tracking software. The clean interface and automation features help you track and resolve bugs smoothly. HappyFox is free for a 2 member and priced economically for larger teams.