I'm very new to Twilio Studio. I'm converting an IVR from OpenVBX to Studio and have been trying to find examples of flows (can you even share flows?) or widgets other than the (very sparse) examples included in the on-line documentation. In OpenVBX, many plug-ins were shared by users, but I can't find anything similar. Does this exist?
It does not, however you can extend Studio Functionality using the Run Function Widget, which allows you to write custom code using Node.
There are many blog post and You Tube videos and tutorials using Studio that should get you started. You can also export the JSON of your Studio flow, if you want to share it with others. Studio provides starter templates as well, when you create a new flow, which are helpful with the initial layout structure.
Twilio Studio Tutorials
Twilio Studio You Tube Play List
Twilio Studio Widget Library
I am developing a project with flutter. But I recently wanted to make a pure dart project. So I pressed "Dart: New Project" on visual studio code. It gave me these options to choose from:
AngularDart Web App,
Bare-bones Web App,
Console Application,
Dart Package,
StageXL Web app,
Web server.
I pressed each of them because I didn't know which one was right for just playing around with dart. But after, I could not figure out where to right my dart code. Can anyone please help?
I'm a student and I wanna start learning this language, I have some experience with C++ projects, it's very easy create, debug you project, add some files. How i can do all of this stuff with lua? Highlighted syntaxes, debug tools, very useful.
I know that on official site you can use lua53.exe file and compile in console, but may be exist more easy way to do it in studio? Also i know that exist a lot of other IDE that can accomplish that kind of stuff, but i get used to VS.
You can use visual-code,
or IntelliJ (with lua extensions).
I am trying to combine obfuscating my xamarin android project and then bundle the assemblies into native code with the Visuals Studio 2017 Pro option.
I was able to obfuscate my assemblies with this tutorial https://blog.noser.com/xamarin-android-code-obfuscation/
Unfortunately the obfuscated assemblies does not find its way into the native bundle.
Likely i intercepted the build proccess at the wrong place.
<Target Name="Obfuscate" AfterTargets="_CopyIntermediateAssemblies" Condition="'$(Configuration)' == 'Release'">
Does anyone know how to merge the obfuscated assemblies into the native bundle? Thx for help in advance.
I help develop another .NET obfuscation/protection tool, Dotfuscator.
We've written a Xamarin build integration that automatically handles protection as part of the normal build process, so you don't have to manually write your own MSBuild targets or copy files around.
The official Xamarin docs recommend using Dotfuscator to protect Android builds, but this integration also works for iOS and UWP.
As Dotfuscator's Community Edition is included in Visual Studio, you can try this integration out for free.
I wrote a guest post for the Xamarin Blog that explains how to do this.
Edit regarding the setting in the question: I did some limited testing and Dotfuscator works fine with the "Bundle assemblies into native code" setting. I installed the latest version of Visual Studio 2017 Enterprise, version 15.7.2, but found out that version has a bug related to this setting. To work around it, I used the unofficial VSIX install mentioned at that link. Then I opened a Dotfuscator-Xamarin sample app and enabled the native code setting. I also added code to the sample to show the name of a class used by the application. Then I deployed the app to an emulator. The app ran normally and the logging statement showed an obfuscated name for the class, indicating that Dotfuscator correctly protected the app before it was bundled into native code.
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.