I have a CRM plugin which I can deploy to Salesforce and it works fine.
My plugin is SPA which is written on javascript with durandal framework and it uses such libraries as knockout.js, require.js, q.amd.js, jquery.js, underscore.js, i18next.js and a few other javascript libraries. Is it possible to deploy such kind of app to Zendesk environment?
Unfortunately, up to the moment no. There is an "ongoing" discussion on Zendesk Support Forums about the matter, but it looks like it's not going to happen anytime soon. Product managers interacted in the thread expressing some will to do it, but I wouldn't rely on that happening in a near future:
At the moment we have no plans to support external libraries. We may open this up to a select few in the future.
Related
Can you explain me how to use Dart flutter with just an ordinary desktop web site?
Let's say I have a website, which has a good responsive design, but I want to make it more handy for mobile users. So, I decide to use Dart, I create a server and then? Do I need to redirect users to f.e. m.mysite.com which is built on flutter widgets, but PC users will redirect to mysite.com? Also, there is an information that since June 2019 you can write desktop web application. What does it mean, we couldn't do that before?
As #Randal Schwartz noted, Flutter Web is in very early stages of development (alpha, I believe), meaning you should not roll with it in production. However, it is the only way to use Flutter to build websites. You can find it at:
https://flutter.dev/web
https://flutter.dev/docs/get-started/web
https://flutter.dev/docs/development/platform-integration/web
If you want to use Dart (not Flutter) in a website, you can try these. They are more mature than Flutter Web, but you'll lose "Flutter" features:
VueDart (https://refi64.com/vuedart/)
AngularDart (https://angulardart.dev/)
React-Dart (https://github.com/cleandart/react-dart) (This one is tricky!)
These are all ports of popular JS frameworks (Vue, Angular, and React) to Dart, so you can use them for responsive website design. Note that you might have to do some background research in the original JS framework, to fill in documentation.
Note: All of the above work on both Mac and Windows. Flutter Web/Dart frameworks are not platform dependent.
Flutter has primarily targeted the mobile platform. What is changing is that Flutter is also being developed for desktop and web applications. Not clear what you mean by "desktop web". Both desktop and web flutter are "not ready for prime time", but progress is being made rapidly.
I am little confused which one is best for build hybrid mobile application.
IONIC Framework, Onsen Framework, IBM Worklight, Sencha or other. I am familiar with javascript, css, and angular.js
There is no "better" framework. They all have their own strength and weakness.
The only things that matter for me when I want to start a new project with a new technology are:
Is it mature enough to be used in production?
Is it still in developpment?
Is it well documented?
Is the community active?
Is it hard to use?
I'm using Onsen UI And Ionic and for what I can tell, both are doing the job, are easy to learn once you know how to use Angular.
Ionic:
Big community and support
Lots of tool to make your developpment easier
Plugins and themes available
Growing project
Onsen UI
Can be used with multiple framework
Good Documentation
Easy Router implementation
Small community
Tools such as Bower, Grunt and Yeoman have surged in popularity recently.
Whenever I've read about them or come across them in an article, I've dismissed them as tools used for Mac-based front-end devs or PC-based but not on the Microsoft stack - Sublime Text etc.
Visual Studio has NuGet, project templates, MSBuild, MSDeploy, TeamCity/TFS Azure etc. and I generally consider VS has being a very highly automated ecosystem (some say it makes us productive at a cost of understanding).
How are these tools being used by ASP.NET devs on VS?
Note: This is not an opinion-based question, I'm looking for real-world examples of how these tools are being used.
There is a Package Intellisense extension for Visual Studio which adds bower and npm package support
Grunt/Gulp launcher extension for launching grunt/gulp tasks
Read this awesome article written by Scott Hanselman for more info:
http://www.hanselman.com/blog/IntroducingGulpGruntBowerAndNpmSupportForVisualStudio.aspx
UPDATE:
These features are now fully integrated into Visual Studio 2015:
http://www.asp.net/vnext/overview/aspnet-vnext/grunt-and-bower-in-visual-studio-2015
Great tips from john papa:
http://www.johnpapa.net/get-up-and-running-with-node-and-visual-studio/
As per Scott Hanselman's blog posting, he says this about the reason why a VS dev might want support for these tools:
Some of you may ask, why not use NuGet for JavaScript? Why not extend
MSBuild for building CSS/JS? Simple. Because there's already a rich
ecosystem for this kind of thing. NuGet is great for server side
libraries (and some client-side) but there are so many more CSS and JS
libs on npm and bower. MSBuild is great for server-side builds but can
be overkill when building a client-side app.
So, use both. These are tools in your toolkit. Adding support for
Gulp, Grunt, Bower, npm (and other stuff, in the future if needed)
means a more familiar environment for front-end devs doing ASP.NET and
it opens the doors for ASP.NET devs to bring in the JS and CSS
libraries communities use every day.
Though I'd still be interested in other people's take on how these tools fit in to the 'workflow' of a VS developer. For example, "Before I installed Grunt, I wasn't able to easily... blah."
Update
I'll stick some updates in here as I learn things.
So, new learning no.1: Yeoman scaffolds front-end, client-side code. Whereas VS scaffolds server-side stuff and project templates (that don't change for months/years), Yeoman can help with boilerplate for fast-changing JS MV* frameworks, for example.
New learning no.2: the tooling is not ready for prime-time enterprise dev.
The first problem is that npm downloads dependent packages into nested subfolders and recurses this model exhaustively, so you end up with folder paths that are 100s of characters long. Windows and some tooling goes nuts. There are workarounds but its a serious flaw.
Latest Node and some added command line options now make this better behaved.
Developers running Windows are often in enterprise settings which means proxy filters and auth. For me, I needed to install Cntlm local proxy to get NPM and other tools to work via our proxy, which violates our IT policy, I just didn't tell them.
Some of NPMs packages seem to want to clone Git repos using SSH! Port 22 is not open; because the community is so Linux/Mac non-enterprise oriented, such issues arise because they're not a problem for so many creative-agency devs and then can hang around for months.
New learning no.3: how dynamically downloaded JS files end up as content in the project file and thus added to an MS Deploy package is still an unknown.
Update on learning 3, we created a build that just transformed the config files, then we used the MSDeploy command line to copy files individually to the destination server. Not something I'd do if I were working alone, it took weeks on and off, to automate all this.
With Bower updates are faster. Every time a new version or update is released we can easily find it in Bower. You no longer have to wait as we had to with NuGet.
So we could say that NuGet continues to be the king in the server side, but Bower is the new king of client-land.
Take a look in this post for more details and see a simple example:
http://nearsoft.com/blog/bower-and-asp-net-5-a-tutorial/
To answer the original question with a perspective from both enterprise and casual development...
History
Visual Studio has always been a standard development tool for efficiently building large-scale enterprise applications for Desktop, Mobile and Web. This included both client-side and server-side web applications built using Forms, MVC and the .NET Framework. Of course, what makes Visual Studio so appealing is the power behind it, which gives developers the ability to quickly generate, or scaffold, common solutions via project templates - allowing developers to focus on solving business problems.
For simple client-side web sites that use a few libraries and require minimal data interaction, a tool such as WebMatrix would often suffice due to being lightweight and able to serve up web sites with ease.
Many of those tools and technologies can be found at Microsoft /web.
Divergence
At the same time, there has existed a burgeoning Open Source community that has been developing many of the libraries and frameworks that have risen in popularity for building modern web sites and web applications.
For developers working with the "Microsoft Stack" of technologies, the gap was originally bridged by integrating NuGet into Visual Studio. Many, but not all, libraries and frameworks were available as NuGet packages; and there was plenty of support from Microsoft for working with these technologies. Microsoft had also created it's own open source mini-ecosystem called CodePlex to support development and sharing of projects, usually focused on their technology in some way.
Unfortunately, while the availability of technologies was fairly up to date for Microsoft developers, it had become more and more challenging to keep up because it wasn't just about the libraries and frameworks, but the workflow and the way these technologies were being made available, integrated and used.
Such workflows include:
client-side package management via Bower from Twitter
(Bootstrap, etc.)
node-based package management via NPM
client-side application scaffolding via Yeoman (e.g. generators for ASP.NET and knockout)
automated task running via Gulp and Grunt
pre-compiling CSS from either SASS or LESS
transpiling languages such as ES6 or TypeScript
testing (Jasmine, Karma, etc.)
bundling and deployment (Webpack, etc.)
Unfortunately, much of this is a manual process, such as identifying the right package for the job or writing different tasks that can eventually be run automatically. Each is truly a subject in and of itself! It's not uncommon to end up simply looking up a package or command for something that in the end could - and Visual Studio developers would say should - be automated.
Convergence
Microsoft has been slowly moving from not only supporting open source development but embracing it. It has made many of its core technologies available to the open source community via GitHub, as well as it's own .NET Foundation movement.
A major effort to converge by Microsoft was to introduce Visual Studio Code for multiple platforms - offering a simplified development experience that caters to the workflow that has become popular with the open source community.
Still, Visual Studio Code can be viewed as a major step back for developers used to much of the power and simplicity offered through Visual Studio through its automation of tasks and project templates. Microsoft introduced Web Essentials for 2010 and 2013 editions to keep up; but as many have observed, this was simply more of an effort to show support rather than a full integration into developer workflow.
Behind the scenes, Microsoft was looking to put it's .NET Framework on other platforms and established .NET Core. As of Visual Studio 2015 - specifically Update 3 and Node Tools - there is much deeper support for the open source development workflow with integration of NPM and Bower, as well as task running. These still require manual intervention but it's on par with the workflow outside of Visual Studio. It still feels foreign, but it's getting there.
The Future
With all that Microsoft has invested, it is clear that the next step is to bring together much of the steps taken to embrace open source development by providing a more visual and automated experience to Visual Studio Developers. This will include templates that generate rich web applications which not only have all of the necessary packages and dependencies defined, but the ability to bundle for distribution.
In the meantime, I think this is a great time for Visual Studio developers to get a feel for the current workflow, if just to appreciate how "the other guys" have been doing it. It won't be long before much of it will be simply a click away.
Could someone please explain something for me.
I am confused. Currently Polymer and Web UI seems to be two separate projects with a lot of similarities.
Is Polymer to succeed Web UI - meaning Web UI will be discontinued in favour of Polymer?
Yes, Polymer is the successor to Web UI. At some point in the future, once Polymer is more stable, Web UI will be abandoned.
For now though, it still may make sense to use Web UI if you need it for a production app.
As mentioned already, yes Polymer is the next version of web_ui. It is being developed in conjunction with the JavaScript version of Polymer. web_ui is currently in extended support mode, in which bug fixes are applied to keep the library functional (particularly as new SDK releases are made), however there will be no new functionality added to web_ui.
As of yesterday, the integrated build reached 0.8.1, and with Polymer 0.8.1, Polymer has virtually reached parity with web_ui and in some areas already surpassed with additional functionality.
Google has committed to maintaining web_ui for existing projects, however I would highly recommend that any new projects be started with Polymer. It is also the time to look at porting any old web_ui projects over to the new libraries (something I'm in the process of doing myself).
I'm about to begin building a website using the ASP.NET MVC framework and I'm trying to find a good solution to 1)Source Control Management and 2)Deployment. For the SCM, I'm probably going to use SourceGear since it integrates into Visual Studio nicely, but for deployment, I don't even know where to start. Up until know, most websites that I've built were very static and every time I had to update the site, I would use an FTP program and just drag and drop the files to the server. But now that I'm going to be building a much more dynamic web application, this approach feels dangerous (which, oddly enough, is also my middle name).
Does there exist some kind of idiots guide or tutorial that explains a good way to deploy an update to your website?
Thanks so much in advance for all your help!
Source Control
For source control, I like to use SubVersion at home. I would recommend using VisualSVN Server to install the server - it's free and ridiculously easy to use.
On the client side of things, I use TortoiseSVN (for shell integration) and VisualSVN (for Visual Studio integration). The small ammount of money for VisualSVN is well worth it, but there is a free open source equivilent AnkhSVN.
That's just what I use and there are many alternatives out there.
Deployment
I would definitely recommend using Microsoft Web Deploy.
Scott Gu just blogged today about it - Automating Deploy with Microsoft Web Deploy. There there is also Scott Hanselman's guide - Web Deployment Made Awesome: If You're Using XCopy, You're Doing It Wrong.
I recently came across a couple of posts by Jon Torresdal using Team Foundation Server (SCM), TeamCity (CI), and Web Deploy to implement a 'no-click' web deployment. They make for very interesting reading but they're definitely not what you'd consider idiots guide material.
No-Click Web Deployment – Part 1
No-Click Web Deployment – Part 2 – Web Deploy (a.k.a. msdeploy)
HTHs,
Charles