I am not sure if this is a valid question here but couldn't find an answer elsewhere. I am just about to starting training on Microsoft Dynamics CRM and with just over an year of experience with asp.net, a little bit of JavaScript, HTML and CSS, I am not sure if I am headed the right way.
Is this sufficient? What skills should I try to sharpen up before starting with Dynamics?
Dynamics CRM is probably the most flexible system I have ever worked on. You can extend it and make it do just about anything. So the first thing you will want to learn about is the different vectors or customization. You can customize CRM in several different ways and each has it merits and drawbacks:
Javascript [Client side only]. Note that CRM doesn't support customization by directly accessing the DOM, rather you work through XRM exposed interfaces. It allows practical GUI and data manipulation though through REST and FetchXML queries.
Workflows. These are rules you can program via the "point and click" interface. It allows you to monitor when certain actions happen and then react accordingly. These run server side so it is independent of the client. The system ships with lots of rules, but custom rules can be written to extend these almost infinitely.
Plugins. Similar to workflows but these fire immediately after subscribed to events. You can do things here like perform validation (which you can also do in Javascript, but plugins are server side) and manipulate data on or after saves.
For custom workflows and plugins, you will definitely need to be familiar with .NET (at least 4.0). You can use either C# or VB.NET, but the Visual Studio integration (which is really nice) is limited to C#. You can use VB.NET but it requires a lot of manual configuration so I wouldn't recommend it given the choice between the two. At the time of this writing, however, the Visual Studio integration is limited to VS 2010 and VS 2012 Professional.
This is just a primer, there is lots more info on MSDN and there are tons of blogs available to help you get started. Of course you can always post your specific questions here on SO for help...
Good luck to you.
Related
Effort:
I am building a word game based on a chat web-client where I need to make a server call on input chat text to validate it before broadcasting on the chat.
I am aware of Meteor providing latency compensation out of the box. But given its still in "early preview" makes me seek other alternatives.
What I tried:
Unfortunately my web search for "latency compensation framework library" doesn't yield anything other than Meteor (including non-personalized results).
Question: Are there any other alternatives that provide latency compensation -or- can make the job easier? I am hoping other developers might have encountered something useful/relevant.
Although Meteor is in 'early preview', its code is very close production ready and a lot of startups and other early adopters are using it for production-level code. You aren't going to find anything that gives you wings like Meteor because no such alternative exists.
As a hardcore Meteor convert and someone who's used many other frameworks, I recommend you to just try Meteor out. As they say, it only takes a weekend for you to build an app in Meteor and decide whether it's right for you.
Having said that, I will attempt to answer the question and list the distant-second alternatives to Meteor that you probably won't want to use:
Derby
Sails
What you're seeing right now in the various real-time full-stack Javascript web frameworks is the future of Web development, cutting down dozens of people and thousands of man-hours of work needed to develop a software project. There are some fast boats sailing that are leaving server-side rendering behind, and you should probably just get in one of them and get going.
RethinkDB uses term 'latency compensation'.
I've also tried to gather per-feature alternatives to Meteor
Meteor is a really cool framework. you can build the complex data driven application very easily using meteor.
But, this framework currently supports only the MongoDB as back-end database.
I have recently created full stack framework called Nooljs which is similar to the Meteor. Now I have open sourced it. It support all the database connections including MySql, ms-sql, and MongoDB. The complex data driven application can be created easily using this framework.
This has been developed using well known existing framework such as Angularjs, Node, express-js, and socket-io.
Easy to build complex data driven JavaScript applications with minimum coding.
Support multiple data connections suck as Ms-sql, MySQL, PostgreSQL, and Mondodb.
Real time framework build top of Express-js and Socket-io
The client side is powered by the Angularjs.
The layout can be build using the Angularjs tags and elements.
Modularized layout to simplify the complex web pages.
Can be mixed both Express-js and Socket-io
I am taking part in Imagine Cup and got only three months for building a site in ASP.NET. Is it possible to learn enough to build a working site containing an cms, login system in a month. Its not that I am beginning web development, I already know a little asp.net and know AJAX, JAVASCRIPT, CSS, HTML, SQL but have never worked with databases. I was never into web development but started because of Imagine cup. In 2 months I already know HTML, CSS, JAVASCRIPT, HTML and AJAX but I am worried about the complexity of server-side scripting and ask for the best way to get me working in ASP.NET in a month. I know c#.
Although you can't be an expert in a month, you can get up and running fairly quickly with webforms. Since it already includes a login system, you can get that up and running quickly.
As far as CMS, it depends what you need. An advanced CMS system is a major undertaking.
Getting going with ASP.NET
Actually, if you want to re-apply everything you know about creating JS enabled static html sites, you'd have a smoother path using MVC because you don't have to guess what the tag id's are, you don't have to guess what kind of HTML a server side control is going to create, etc.
That said, Jonathan Wood is correct, to just create a page with labels and buttons, Web Forms has fewer concepts you need to learn, but you will find it harder to apply the same techniques that work well with JS + static html.
Data bases
If you use SQL Compact, then it is easier to get started because you needn't learn to mess with the numerous things going on with SQL Server (like a security model appropriate for big companies, but not for learners). Another easy alternative is MS-Access because the "Query by Example (QBE)" query designer is still better than anything that the Visual Studio or SSMS teams ever put together.
Keep in mind that if you use MS-Access, while it will be really easy to learn (more so than SQL Compact), MS-Access uses Jet SQL and has many other differences from SQL Server, where as everything you learn about SQL Compact will apply to SQL Server.
Not sure what the conditions etc of Imagine cup are, but I strongly recommend to use an existing CMS (in particular Umbraco) instead of developing all from scratch. Some advantages are:
No need to dive into SQL and databases right away
Building blocks are available (login system) and leverage existing ASP.NET technologies
Razor can be used instead of xslt which will be a skill you'll be able to apply to pure ASP.NET MVC development later on
Very friendly and helpful community if you need some help
Starter kits available - basic web sites can be created easily
By diving into any detail of the CMS, you'll learn a lot (source code available)
You could probably pick up the basics with a few good books. Sam's, Wrox, APress and O'Reilly are great. You can also check http://www.asp.net/get-started for Microsoft's official tutorials.
You can also download the express versions of Visual Studio 2010 and SQL Server. If you want to continue on after the competition I'd strongly recommend you learn database programming on SQL Server 2010 Express. (It'll help you down the road)
Good luck with it.
We've made a big investment in Microsoft BizTalk Server 2009 and it works like a dream for all our asynchronous work. We want to do much more synchronous work with it, though, and that's why we're seriously looking into the ESB Toolkit 2.0.
However, I've had issue after issue with this toolkit, and my gut feeling is that it falls short of being enterprise-ready. In other words, there are just too many bits that need to be installed in the absolute correct sequence, and too many things that can (and do) go wrong - too much hacking of .config files to get it to work, documentation full of errors, exception messages with spelling mistakes, etc.
Anyone share that opinion?
Is anyone actually using this toolkit in a live production environment?
Have you got BTS 2006/2009 but decided against using ESB Toolkit?
Really interested to hear some opinions.
Thanks
Andrew
I think there are many developers and projects out there that found the same issues about the ESB toolkit that you describe. I've seen a handful of projects and companies leverage the toolkit but usually what I see is that the source code is used (not the MSIs and/or compiled code, the source is cleaned up and only parts of it are deployed on the project. I've seen the ESB portal be used the most for its "out of the box" error management features and since its ASP.NET I've seen and been part of extensions built for it. I think it will get there, kind of reminds me of the early years of the enterprise library, in my opinion it only got enterprise ready after 3-4 years of development.
We have spent a few years improving the ESB Toolkit, making is useful. We have a SharePoint web part (that can be used with SP Foundation).
There are quite a few enhancements. To name a few:
Re-submission at the point of failure (instead of the beginning of the itinerary)
Friendly XML editor (instead of a string editor)
Logging of business data
Ajax portal (no pressing F5 all of the time)
Visibility into all of the steps of the itinerary (what has happened, what is next)
Logging of who made modifications
This may sound a bit general, but I have a startup that is working on an ASP.NET (greenfield) suite of software applications. We are aiming to spend a substantial amount of time in the architecture phase to develop a strong foundation for our software. I was wondering if anyone has any advice, anything we should focus on or any suggestions for areas we should focus on to build a better suite.
Some things we are focusing on right now:
1. Session state requirements - should sessions be sticky or should we take server clustering session migration into account.
2. User login authentication - what are the major concerns in this space - LDAP, AD, custom SQL authentication systems etc.
3. The DAL - ORM vs Stored Proc
4. Integrating multiple ASP.NET applications in a single software suite. How it should look/feel. How it should be architected, etc.
I would appreciate any advice from any architects out there that have built similar systems from the ground up.
I know there are lots of solutions to session, but if you can create your framework to be session-free, you will avoid a lot of potential headaches. (There are lots of session-free options, but an obvious one is a hidden form field, somewhat like ViewState.)
Just some quick notes. I can't get too detailed since we went through this exercise where I worked last year - and I don't work there any more!
Start from the beginning using Enterprise Library, especially the Logging and Exception Handling application blocks. I've also found their Unity dependency injection library to be very useful.
Consider using Visual Studio Team Foundation Server. It's not just for source control, but can create you a complete continuous integration solution, complete with integrated bug tracking, code quality tracking, etc. If you've got the time and people, it's well worth a man-month to learn how to do an initial deployment.
You may want to buy one or more licenses of one of the Visual Studio Team System editions. You don't need these versions in order to use TFS, but they work well with it.
Consider globalization right from the start. Same with customization, if your suite will run on customer premises and be customizable by them.
You haven't said how large your team is, or is expected to be. If it's large enough, you'll want to spend at least a man-week learning a bit about what's available to you in terms of Visual Studio Extensibility. Your developers (and maybe also your QA folks) will all but live in Visual Studio, so the ability to customize it to meet your needs can be a big win. Whether it's just some macros and maybe some customized project or item templates, or whether you want to do add-ins or more, Visual Studio is very extensible.
Be certain to use WCF for any web services work. The older ASMX web service technology is now considered by Microsoft to be "legacy software".
Finally, be sure to find out whether you qualify for BizSpark, "A program that provides Software, Support and Visibility for Software Startups." And does so almost for free.
I saw a demo of Silverlight 3 at the PhillyDotNet User Group last night - WOW. Wow for business applications, not graphic applications. There is a learning curve, but you get a lot for it. For example, the demo showed a grid being bound to a table without needing to write any code.
Right out of the box you had sorting, editing, paging, etc. But it wasn't the lame stuff you normally get and then have to rework. For example the paging was smart enough to write the sql that would only bring back the 20 rows you needed for the page.
The demo continued with him putting a detail form on the page for editing. Again no code, but it was smart enough to know that it had the same datasource as the grid on the page. So as you were moving row to row on the grid - the detail form was showing the current row (and it was very fast).
Both the grid and the detail form were editable and as you changed a field in one the other would reflect the new value. The editing was smart enough to validate the field on its own. So you couldn't put a letter in a field that was an integer type, etc. It also limited the number of characters that could be entered based on the column size found in the database. All the date fields on the detail form automatically had a calendar next to them. You get the idea - no coding for any of this.
If this weren't enough, it can be used to build occasionally connected applications. So he showed how he updated a few records on a few different pages, had the option to revert back a field later (ctrl-Z), and then at the end submitted all the changed records to be saved.
Also, they said it works with Linq2SQL and the entity fraimwork.
So if I were building a new product now, I would really look into this as a way of differentiating my product. And I suspect that if you don't do it with Silverlight now, you will be rewriting it in a few years anyway.
Here is a link to a demo (not the one I saw.)
Some general thoughts. If you'd like me to expound on any of these, let me know.
Inheriting from a custom subclass of
Page instead of Page itself is a
great way to share functionality
across your site.
Nested MasterPages are good.
Charting: I've tried DevExpress,
Syncfusion, and MSChart control and
all have their own issues.
The built-in forms authentication is
pretty good. Building a site that
allows both integrated authentication
and forms authentication is tricky
but can be done.
I've tried using cross page postbacks
and I'm still not sure if I like
them.
Localization takes a lot of time
Come up with a good structure for your App_Themes and css.
Use Elmah to track unhandled exceptions
We need to build an administration portal website to support our client/server application. Since we're a .Net shop the obvious traditional way would be to do that in ASP.Net. But Silverlight 2 will be coming out of beta a good while before our release date. Should we consider building the whole website in silverlight instead, with a supporting WCF backend?
The main function of the portal will be: users, groups and permissions configuration; user profile settings configuration; file upload and download for files needed to support the application.
I think the main reason for taking this approach would be that we have good experience with WPF and WCF, but little experience in ASP.Net. Either way we would have to learn ASP.Net or Silverlight, and learning Silverlight seems a more natural extension of our current skills.
Are there any big no-nos from the experience of StackOverflowers? What are the big positives?
I would recommend against building a pure Silverlight site.
Silverlight suffers from the same issues as Flash does: Unintuitive Bookmarking, issues with printing, accessibility issues, not working back buttons and so on.
Also, you would require your users to have Silverlight installed or at least to have the ability to install it.
In controlled environements (eg. in large companies or health care) or on mobile devices, this might not be the case.
I would definitely go for a full Silverlight application, specially if you have good experience from WPF. You will be able to reuse your knowledge from WPF, and should be able to pick up Silverlight fairly quickly. I've been working with Silverlight since Beta 1, and the current Beta 2 is of solid quality. I guess it's safe to assume that a RTW version is just around the corner.
Pilf has some valid point, specially around printing. For that I would probably use SQL Reporting Services, or some other reporting framework, on the server side, and then pop up a new window with printable reports. For linking and bookmarking the issues are no different than any other AJAX application. I did a blog post today about how to provide deep linking and back-forward navigation in Silverlight.
Silverlight also has all the hooks needed for great accessibility support, as the UI Automation API from WPF is brought into Silverlight. I don't know if the screen reader vendors have caught up yet. The styling/template support in Silverlight makes it easy to provide high-contrast skins for visual impaired users if that is a concern.
Depends on your goals. If administration portal is part of application and will only be used from computers where your application is installed, there are plenty of advantages of going fully Silverlight - or even WPF.
But if you can see a scenario where it will be used either from random PC or by random person, fully functional HTML/Javascript version is absolutely necessary.
Some reasons are:
Most people don't have silverlight and you'll earn a good load of swearing if they have to download and install it. Some people who have it installed keep it disabled (together with flash and sometimes even images) to avoid distractions and speed up browsing.
When HTML site fails, user gets error page and reloads. When silverlight fails, it can hang or crash.
HTML is what is expected - both by users and web browsers: back and refresh buttons work as they should, hyperlinks and forms work as expected.
Slow internet is still very common, both in remote areas and mobile devices.
I agree with what everyone had said so far and I think this Flow Chart, which is aimed at Flash, also applies to Silverlight.
Source of Image
It sounds like your problem is that you need a rich-client admin application. Why not use click-once?
On the topic of remote andministrators, another poster stated that was an argument in favor of HTML if the admins were on a slow connection. I would argue that depending on the type of information, it may be more efficient to use Silverlight. If you have an ASP.NET datagrid populated with server side data binding, you can be downloading a ton of markup and viewstate data. Even if you're using an alrternative to DataGrid that's lighter on the ViewState, you will still have a lot of HTML to download.
In Silverlight, once you get the XAP down, which is probably going to be smaller than the corresponding HTML, the XAP is cached and so you shouldn't have that cost every time, and you'll just be retrieving the data itself.
For another example, let's say you have a bunch of dropdown lists on one of your forms which all have the same values in the list. In Silverlight, you can get these values once and bind them to all of the dorpdowns, in HTML you will have to repeat them each time.
This will get better with client side data binding in ASP.NET, which follows a very similar model to Silverlight and WPF for data binding.
Overall, I would also think that you would need to write less code for the Silverlight implementation which can increase productivity and reduce maintenace costs.
ASP all the way. You should only use silverlight/flash etc when text can't do what you want it to do - e.g. display video.
Using a plugin for your website makes it slow, and requires the user to have the plugin installed. Silverlight for instance rules out all Linux user. Also, since Silverlight is pretty new, there is no telling how committed Microsoft will be to keep the platform alive if it doesn't pick up soon.
I'd stick to plain old HTML with server side scripting.
Also, for public websites: Flash and Silverlight can't be indexed by any search engine, so good luck with writing tons of metadata if you want any visitors at all.
Silverlight is a good choice for an internal-facing portal, just as it would be for a public-facing portal if you've already evaluated your project and have decided to go forward with a web portal. You are free to integrate Silverlight components within an existing ASP.NET application (i.e. the "islands of richness") approach, but if you have the ability to build a new project from scratch, don't discount a completely Silverlight solution as a valid choice where you would have went with a traditional ASP.NET portal. Silverlight is RTW now, so if this decision is still on the table, you know you won't have to deal with breaking changes going forward.
There are some downsides with developing a site completely in Flash / Silverlight, but if those downsides won't matter to you or won't have an impact then there is nothing stopping you. Choose whatever tool you think meets your needs more fully. I wouldn't be put off creating a site purely in Silverlight based on the downsides, because it brings a lot more positives to the user experience.
The previous comments have dealt with most of the downsides of using Silverlight for a site like this and I agree. If you're determined to have rich-client style development and your audience is small (for admins only) then I'd probably recommend WPF over Silverlight as it currently provides a richer set of tools and controls.
If you stick with ASP.NET have you looked at Dynamic Data - it's ideal for building backend management sites with little effort.
I've seen "Silverlight only" websites at Microsoft and they are pretty impressive. But again, the demos were there to exploit the full potential of what Silverlight can do. The moment you need something different you may be out of luck. I don't see Silverlight like Flash except in the way they are installed/seen. But the Flash/ActionScript backend is really bad compared to what Visual Studio can offer with .NET
Ask yourself why would you like to use Silverlight? Fancy effects or programming model?