Here's the deal : we have a big product with legacy, and custom code to handle minification, packing, compilation (for less files) for all our front end assets.
We think about using wro4j, but I've come across multiple articles advising to use grunt or gulp instead.
I'm here to find advices about which is the best choice.
With JS advanced beyond just minification, packaging to transpilation and tree-shaking etc there is definitely a plus to using grunt and gulp where such features are supported. In wro4j you have limited choices for processors available. https://wro4j.readthedocs.io/en/stable/AvailableProcessors/
Hence you have to write your own custom processors to support new features in your build process.
Plus, I am an advocate that front-end developers find it easy to understand/edit build processes written in their native language (grunt and gulp use JS) than having to learn Java and Maven to get familiar/working with wro4j
Related
I have painfully come across the facts that scala.util.parsing and scala.swing are apparently no more bundled in Scala 2.11. Each time, I had to google for the right line to add to an sbt configuration, or to find the right link for where to download the jar file.
In case there are other libraries that moved out, how am I supposed to know these things? Or am I supposed to rely only on questions from people having the same problem on Stackoverflow? The Scala Swing project on github does not even document these info.
I like creating Eclipse projects on the fly, and making them depend on other projects in the same workspace, without going through sbt, and it is annoying to run into these library disappearance cases on every computer/workspace where I do this.
The modularization (what you call externalizing) has been discussed for a good while on the scala-users mailing list. But the canonical place where to find this information is in the release notes. While you may not want to read all of those, I would strongly advise reading at least the release notes for a major version of any language you use. Case in point, the release notes for Scala 2.11.0:
Modularization
The core Scala standard library jar has shed 20% of its
bytecode. The modules for xml, parsing, swing as well as the
(unsupported) continuations plugin and library are available
individually or via scala-library-all. Note that this artifact has
weaker binary compatibility guarantees than scala-library – as
explained above. The compiler has been modularized internally, to
separate the presentation compiler, scaladoc and the REPL. We hope
this will make it easier to contribute. In this release, all of these
modules are still packaged in scala-compiler.jar. We plan to ship them
in separate JARs in 2.12.x.
What are the easiest ways to code a VST plugin?
I'm a sophomore in IT education, and I may need to write a VST as an assigment project for Digital Signal Processing course. This means I will probably have to implement an actual DSP algorithm, so if I'm not wrong, that outrules all graphical modular VST maker software.
I currently have C++ (CodeBlocks + MinGW), Java (Eclipse), Python and Octave at my hand. I can also get Visual Studio, Matlab, or some free language/environment for the task. I have also found Faust which is a functional language and I may learn that for this project, because I enjoy learning new languages.
SynthEdit is probably the easiest way to create a working VST plugin while getting the chance to write low-level DSP code. SynthEdit can be extended with custom C++ modules. You could write a module containing your custom DSP code to satisfy your course requirements while using SynthEdit for the GUI and the other VST 'glue' type code. Writing DSP code is only one small part of building a VST plugin from scratch.
If you must write a VST plugin and can't use SynthEdit or similar environments I think the next easiest way would be C++ and JUCE. I don't use either but AFAIK most plugins are written in C++ and JUCE is often praised.
Other VST framework options exist such as VST.NET or Delphi ASIO and VST Library but these are less widely used and you'll likely be more on your own if you run into problems.
I think there are VST modular synths that allow you to custom program the DSP logic, SynthEdit comes to mind but there are more. Search for 'vst modular synth'.
If you like to venture into the .NET world, VST.NET is excellent for beginners. It has a framework that structures and simplifies the VST plugin standard and comes with samples that demonstrate the common plugin scenarios.
There are several packages out there that help in automating the task of writing bindings between C\C++ and other languages.
In my case, I'd like to bind Python, some options for such packages are: SWIG, Boost.Python and Robin.
It seems that the straight forward process is to use these packages to create C\C++ linkable libraries (with mostly static functions) and have the higher language be extended using them.
However, my situation is that I already have a developed working system in C++ therefore plan to embed Python into it so that future development will be in Python.
It's not clear to me how, and if at all possible, to use these packages in helping to extend embedded Python in such a way that the Python code would be able to interact with the various Singleton instances already running in the system, and instantiate C++ classes and interact with them.
What I'm looking for is an insight regarding the design best fitted for this situation.
Boost.python lets you do a lot of those things right out of the box, especially if you use smart pointers. You can even inherit from C++ classes in Python, then pass instances of those back to your C++ code and have everything still work. My favorite resource on how to do various stuff is this (especially check out the "How To" section): http://wiki.python.org/moin/boost.python/ .
Boost.python is especially good if you're using smart pointers or intrusive pointers, as those translate transparently into PyObject reference counting. Also, it's very good at making factory functions look like Python constructors, which makes for very clean Python APIs.
If you're not using smart pointers, it's still possible to do all the things you want, but you have to mess with various return and lifetime policies, which can give you a headache.
To make it short: There is the modern alternative pybind11.
Long version: I also had to embed python. The C++ Python interface is small so I decided to use the C Api. That turned out to be a nightmare. Exposing classes lets you write tons of complicated boilerplate code. Boost::Python greatly avoids this by using readable interface definitions. However I found that boost lacks a sophisticated documentation and dor some things you still have to call the Python api. Further their build system seems to give people troubles. I cant tell since i use packages provided by the system. Finally I tried the boost python fork pybind11 and have to say that it is really convenient and fixes some shortcomings of boost like the necessity of the use of the Python Api, ability to use lambdas, the lack of an easy comprehensible documentation and automatic exception translation. Further it is header only and does not pull the huge boost dependency on deployment, so I can definitively recommend it.
Inside a Java project I use Google Protocol Buffers (GPB) for serializing my objects. I can use the same .proto files in auxiliary Python code, which is great. Now I'm adding a Flex client to the whole thing and I'd like to use the same .proto files once more.
It seems there's a couple of projects out there which compile .proto files to Actionscript. From a few glances at the projects' homepages, it seems to me that protobuf-actionscript3 is actually the most advanced and most "alive" of these projects.
Has anybody had practical experience with GPB to AS3 compilers and which one(s) can you recommend (or recommend against)?
If you're sure you want to use GPB, then protobuf-actionscript3 is your best option. It builds on the semi-successful protocol-buffers-actionscript project: http://code.google.com/p/protocol-buffers-actionscript/
If you're open to looking at other formats, there's always Adobe's own AMF3. It seems to have a good amount of community support behind it.
The only choice now is https://code.google.com/p/protoc-gen-as3/. All the other Protobuf/AS3 projects are out-of-date, and lack of features.
I'm using Mercurial for personal use and am conteplating it for some distributed projects as an alternative to SVN for various reasons.
I'm getting comfortable with using it for self contained projects and can see various options for sharing however I haven't yet found any guidance on managing common libraries to be included in multiple projects in a similar manner to that provided by externals in subversion.
The most obvious shared lump of code is error handling and reporting - we want this to be pretty much the same in all projects (its fairly well evolved). There is also utility code, control libraries and similar that we find better to have as projects built with each solution than to pull in as compiled classes (not least because it ensures they are kept up to date, continuous integration helps us address breaking changes).
Thoughts (I hate open ended questions, but I want to know what, if anything, others are doing).
Mercurial 1.3 now includes nested repository support, which can be used to express dependencies. The other option is to let your build system handle the download and tracking of dependencies using something like ivy or maven though those are more focused on pulling down compiled code.
The world has changed since I asked that question and the solution I now use is different.
The simple answer is now to use packages (specifically NuGet as I do .NET) to deliver the common code instead of nesting repos and including the projects in a solution.
So I have common code built into NuGet packages by and hosted using TeamCity and where previously I would have an external and include the project/source I would now just reference the package.
Use the Forest Extension it emulates svn externals for HG, to some extent that is.
Subrepository (with good guide) or Guestrepo "to overcome ... limitations" (of subrepos) is today's language-agnostic answer