The inversify docs say
The reflect-metadata polyfill should be imported only once in your entire application because the Reflect object is mean to be a global singleton. More details about this can be found here.
If your environment don't support one of these you will need to import a shim or polyfill
I'm using LTS node+express for my server. And latest angular for my client.
So I assume:
I don't need it for my server project, because LTS node doesn't need these shims
I don't need it for my client project, because angular bundles various shims automatically
Is that correct? When would that package be needed?
Turns out it doesn't work on the server without this polyfill. Seems that it's necessary for inversify to work, even though I'm using the latest LTS node.
Related
We have a web app project that still uses NuGet for content packages management (jQuery, Knockback, knockoutjs, etc.). We are trying to convert to use LibMan, and running into an issue where some older packages do not exist (for instance walltime-js). How do we work around this issue?
Try using a different provider. The current default, Cdnjs, is a curated catalog; the other two providers, JSDelivr and Unpkg, host any package that's available in NPM and thus have much broader catalogs.
I'm developing a Service Fabric-based trading platform that will host hundreds of different long-running trading algorithms, all of which conform to a common interface and share a good deal of common code but can be vastly different in their internal specifics. I could model each of the different algos as an application type (which I'd dynamically load) but given the large number of different algos I have to wonder if in makes more sense to create a single Plugin Runner application type then implement the algos as plugins.
In a related question, I understand how to implement a plugin architecture, in general, but I'm not quite sure where one would place the actual plugins in order to be discoverable by an instance running on Service Fabric.
Anyway, thanks for your help....
Both approaches can work I think. Using lots of Application Types adds the (significant) overhead of running lots of processes, but allows you to use and upgrade multiple versions of the same algorithm running simultaneously.
Using the plugin approach requires you to deal with versioning yourself.
Using the Application approach probably requires some kind of request router, while the
plugin service could make it's own decisions (if it's stateless).
You can create a Stateful service that acts as the plugin repository, or mount a file share, or use a database, no restrictions from the platform here. You can use naming conventions to locate the proper plugin.
The following approach could work if an application upgrade is acceptable to you when changing the set of plugins needed for a given application instance.
Recall that Service Fabric apps must be packaged before deployment or upgrade. Using either msbuild tasks or Powershell, you could copy your plugin dlls to the plugin runner service's code package as a post-packaging step prior to the app upgrade. Then your plugin dlls would be available to the service at startup using Assembly.Load and the code package's path, available in your service implementation's Context.CodePackageActivationContext.GetCodePackageObject("Your-Code-Package-Name").Path property. The code package's name is defined in ServiceManifest.xml, and is named Code by default.
In setting up Sitecore 7.2 at my organization for our public facing .com I have run into a hiccup while trying to implement proper CI, Release Management, and Deployment Management. I am able to, using MSBuild, compile my Sitecore MVC code, compile .update packages from TDS, and package each of these in .nupkg files for Octopus Deploy. What I am running in to is that once I have deployed the MVC code I must also deploy the Sitecore Structure/Content which requires me to install .update packages. I have tried the solution provided at https://github.com/adoprog/Sitecore-Deployment-Helpers but for a fairly lightweight site this is timing out around 20 minutes within Octopus Deploy for only my System package, let alone having not touched Structure or Content. I am looking for a way, preferably through PowerShell (not strictly speaking, the Sitecore PowerShell Extensions built into the sitecore web interface after installing that package). Using the SPE would be acceptable if, and only if, I can use SPE's Cmdlets from Octopus Deploy's PowerShell workflow.
Please Advise.
Jason Bert has a great series of blogs on using Octopus Deploy with TeamCity and TDS for deploying to Sitecore instances:
http://www.jasonbert.com/2013/11/03/continuous-integration-deployment-with-sitecore/
You can also use TDS itself to deploy the items in the solution, but this uses direct calls to a webservice on the target Sitecore instance which may not meet with your requirements.
Also, are you deploying the entire System tree? 20 minutes to deploy changes made to the System tree seems unusual, unless you've made a LOT of changes in there (for example, the Dictionary). Even then, you shouldn't be source-controlling author content, only the elements crucial to the solution that are owned by development.
You can install the update package via sitecore utility at /sitecore/admin/UpdateInstallationWizard.aspx
If you experience that installing the package via this mode takes a lot of time, you might want to modify the Deployment Property Manager settings for the TDS project.
You can do this by right clicking your TDS project in Visual Studio and selecting "Deployment Property Manager".
Once the Deployment Property Manager window opens up, set the Deploy property to Once for every node which does not need to be updated. For any items which are to be updated, mark them as Always.
This will drastically save you on the time required to install the package.
Can I expect that I replace the Java .jar files and client-side .js files of version 2.4 or 2.5 of CometD in an existing software that is running fine, with the same files in 2.9.1 and it all runs the same?
1- Are the API of CometD exactly the same on all 2.x versions?
2- Is there an upgrade guide that I can use?
Also, I noticed that on the client side, CometD 2.4/2.5 is not AMD and is a single file, but on 2.9.1 it is AMD-based. Is there a single .js file that contains all client-side CometD code?
You can expect upgrades from 2.4/2.5 to 2.9.x to be either without problems, or requiring very little changes, so yes, it should be typically be a drop-in replacement.
While you're upgrading, I suggest to move to CometD 3. You can find here the migration guide from CometD 2.x.
CometD 2.9.x is AMD compliant, and the single file you should include in your HTML is typically org/cometd.js along with a binding for a toolkit (either jquery or dojo).
If you use extensions, you should add also those, see for example http://docs.cometd.org/3/reference/#_primer, or if you don't want to use Maven, this other section.
Follow also the tutorials, that should get you going.
Full documentation link.
Our organization builds web applications using PHP/Informix.
Currently we do not have any frameworks and use our own libraries and modules.
Now we set up a new apache web server so that we could install and configure a framework where all brand new web applications can be developed.
I was thinking of setting up the Zend Framework.(Will it go with informix backend?). I have googled and looked around for information , but I thought would get some expert opinions from the experts here.
I need some advice as how to go about from scratch the correct way.
Installing,configuring,setting up a version control and writing a script to test all basic MVC features.
Any suggestions and references would be helpful.
If you are using Informix Dynamic Server as your backend, then yes you can use Zend Framework's native database classes and adapter for communicating with your Informix server.
Your requirements will be that PHP must be compiled with PDO support (enabled by default since PHP 5.1). You then need to download, compile, and install the PDO_IBM Pecl package.
In order to successfully build the PDO_IBM extension, you must have the DB2 client (9.1+) installed on your system already. When you compile the extension module, you must tell it the path to where those files are installed.
More information on PDO_IBM, and Zend_Db_Adapter talks a little bit about the available adapters (including PDO_IBM).
There is also a Pecl package PDO_INFORMIX for talking to Informix servers, but Zend_Db does not support this package. You will only be able to use Zend_Db_Adapter with PDO_IBM to communicate with IDS servers.
Hope that helps.