I have an instance of ckeditor4-react running, but I want to add a control (such as a customised dropdown) of my own design.
The documentation largely talks about adding files to the node_modules folder, which makes sense in theory, but is going to be a problem for deployment when the build script runs npm i. For that matter, I would expect this to be a common problem.
So my question is, how do people usually work around this?
I need:
A way to develop the customisation (in a sandbox is fine).
A way to deploy it that doesn't involve too much specialisation of the existing deployment system.
Related
I'd like to create an Alcatraz plugin that adds a new project Build Rule to Xcode. Currently our tutorial requires that the developer manually add the rule, pasting in a script. None of the current plugins appear to add build rules -- is it possible?
It's probably possible because when writing a Xcode plugin you basically gain access to all Xcode's private classes & methods + the current Xcode state in memory. So yes, with a good amount of reverse engineering it should be doable.
Now I doubt this is a very good idea as such a plugin would act at the IDE level and not a project level, so you'd have to ask the user to select a project before adding the build rule.
From my point of view, building a plugin for this is way overkill, and a tutorial is good enough (you're interacting with developers after all, they probably know how to click a few buttons), and if you really want to take your users by the hand I'd recommend using a script (bash, python, ruby, etc.).
Crashlytics and Cocoapods both require to add a build step to the developer's project, and they both seems to do pretty well with instructions / a script.
We have some JSP code to run in our pages.
There is a UI designer who will constantly update the UI but does not have Tomcat server. We prefer he doesn't because he isn't a programmer.
However, it is getting annoying to have to cut and paste the JSP related code each time he updates the UI.
Is there anyway to handle this issue? We prefer to keep the same files, but still have it so he can see his UI work without worrying about the JSP and when he checks in the new files, we don't have to cut and paste our JSP related code.
One example of such code, is that there are certain navigation menu items which are displayed depending on the user.
We are using Tomcat authentication. We could I suppose use AJAX to obtain the user information, but is that less secure? Everything else in the application is AJAX.
The problem here is that this person is not working with the team. Rather, he's creating work for them... and it goes both ways. Read on.
I both do and manage front end development. If this UI person was on my team, I would force him to set up a Tomcat server. He just needs to learn some things.
In effect, when implemented properly, JSP is not much different from any other server-side markup language for views, such as Rails + ERB, PHP, .NET etc... even Javascript templating engines (mustache, handlebars, etc.). The same condition checks, for-loops, auth checks - all basic view-layer logic that is needed is available and usable.
If he's on a Java project / team, he needs to learn the Java front-end. It's that simple.
His main tasks should be basic, and frankly, he shouldn't even need to install a Java IDE to do them. They are:
Get/push source code + analyze diffs (any source control client)
Build / deploy latest to his local environment (scripts or .bat files)
Work on the running app*
(*) The last part is where things get tricky. If you work directly on the running server and then accidentally run a fresh deploy before copying over your updates, you're screwed. If you use symlinks (which are also available in Windows), there may be files that only appear post-compilation, or locks, or sync issues when getting latest code - all creating problems.
The way I have found that works best is to work on the code repo location (pre-build), and create two scripts:
Build+deploy - stops running server, blows out directories and caches, builds latest, and redploys
Update - Synchronizes the View files and any other necessary directories with the deployment target. You must be sure to disable hot-deploy in the Tomcat config, or you'll get memory leak errors.
That said, and it should be obvious by now: Java is one of the most difficult ecosystems to develop UI's for. The compiled nature and complex environment requirements make development slow and tedious, with significant dependencies on different people or systems to make a decent product.
JSP itself, while capable as described above, is almost always organized badly, with various ways of includes, tagfiles, partials, frameworks - it becomes a UI person's worst nightmare. GSP (from Grails) solves a lot of the organizational issues, but will require flexibility from the dev team. Even then it is not an "ideal" solution.
JSP syntax - JSTL, C:tags, etc. creates even greater headaches. Front-end people who do not program, don't use IDE's and therefore don't have a way of looking up methods, objects, parameters etc. when writing or customizing conditional logic or loops. The dev team can help by pre-writing these out on the page, but any time there are changes or enhancements needed, it requires meetings, conversations, and compromise.
In the long run, you should abstract the Java app from a separate, more flexible, more capable front-end technology stack, using REST / JSON-based services to talk between the two. (Side note: For performance / apps with scale, ensure you are using either a custom protocol or Web Sockets).
My preference is node.js, because front-end developers can stick with the language they will know best: Javascript / JSON. But it could be anything that your particular front-enders are comfortable with and can do design with.
The key is to eliminate bottlenecks on both front-end and back end. Both tracks should be able to develop and iterate quickly, with the RESTFUL API being the key point of collaboration.
Lastly, for those of you who are aspiring front-end developers / designers but only know Java (or some other server-side technology), I CHALLENGE YOU to learn something new. User-facing technologies are in a constant state of change, and more recently that change has accelerated. If you want to have UI-competitive products, you need to invest in technologies that will make them competitive.
Disclaimer: I am relatively unfamiliar with the flash build processes, so some/all of this may be misinformed nonsense. Please feel free to suggest alternative approaches.
We're currently developing a flex web app and our build situation is far from ideal. At present we're (as in individual developers) just building using FlashBuilder and deploying manually. The programmers are currently screaming bloody murder for two reasons, though:
The lack of CI is like going back to the stone age
We don't much care for FlashBuilder
(Note: We're only using FlashBuilder because it was the easiest way to set up a flex project in conjunction with Away3d and get it building / rendering correctly -- it's a stopgap solution).
As a predominately .NET development shop, we're used to doing continuous integration as well as continuous deployment. Ideally, we'd like to get something comparable to this for our flash projects without tying ourselves to a particular IDE.
Requirements:
The build process must be:
.. runnable via the commandline
.. runnable on both developer and CI build machines (and certainly not requiring an IDE!)
.. preferably as IDE-independent as possible (pragmatism will kick in though; if this causes a lot of friction we'll just pick one).
.. able to run on Windows (we develop using Windows)
We don't mind a touch of duplication or a few manual steps (e.g. tarting up the build scripts if we add a new project via an IDE, or generating one configuration from another if tools exist), but the less duplication / maintenance required the better.
I've read quite a few articles / blog posts and watched some short screencasts, but most of them are very thin on the ground on how the build system sits alongside IDEs. Most articles/screencasts have the same formula: How to create a "Hello World" build using a single file & text editors (no IDE).
I've not seen the topic of multiple libraries/projects etc. being broached, either.
After reading around the issue for a while, I'm considering investigating the following options:
Project Sprouts
Flexmojos
Maven Flex Plugin
buildr as3
Does anyone have any experience of the above solutions (or others I'm unaware of) and, if so, what do you make of them? Any help / pointers appreciated.
I recently started building with Gradle and the GradleFx plugin and I immediately fell in love with its power and ease of use.
Gradle is ANT + Maven + Ivy evolved and is primarily used from the command-line. You can:
write scripts in Groovy (a powerful Ruby-like language that runs in the Java Virtual Machine)
access all existing Maven and Ivy repositories as well as your own repos
use existing ANT tasks
integrate with CI (in Jenkins you just tick a checkbox to activate Gradle support)
although it has originally grown from the Java/Groovy community, it is in fact language agnostic. You add language-specific plugins for added functionality. GradleFx is such a plugin that provides you with additional ActionScript/Flex building tasks.
do easy multi-project builds. e.g. you can compile, unit test, package and deploy both your .NET service layer and your Flex client application with just one command.
use convention over configuration: if you stick to the conventions, your build scripts will be extremely terse
generate all kinds of reports: unit testing, checkstyles, codenarc, ...
generate Eclipse, IDEA or other IDE projects
all the things I haven't discovered yet
And best of all: it's very easy to learn. I had no knowledge of Maven before I started with Gradle and could get a multi-project build with some customizations working quite quickly.
Edit (comparison to Buildr AS3 and Maven)
I can compare this only to one of the projects you mentioned: Buildr AS3. It seems to start from a philosophy that is similar to Gradle's. But I've tried to use it about half a year ago and couldn't even get a simple 'Hello World' app to work. I e-mailed the developer for help: no response.
Compared to GradleFx: I had a small forum discussion with the developer (on a rather philosophical topic, since I didn't really need any help because it just worked right away). He answered within minutes.
As for Maven: (for what it's worth) I've only glanced at some configurations and they seem overly complicated when I compare them to a Gradle script.
There is one thing Maven does that you can't do with GradleFx (yet). It can pull the right Flex SDK from a Maven repo and build against that. With GradleFx you have to have your SDK's available locally.
I'm quite familiar with using maven as the main build tool and the flexmojos plugin from Sonatype. My experience has been a bit of a roller coaster with flexmojos. Maven is completely solid, it works all the time without issue, the only issue is the flexmojos plugin which has fluctuated a lot between versions. If you choose to go this route make sure to grab the source for flexmojos so you can see what your configuration options are actually doing to the command line parameters etc. For Flex 3.x flexmojos 3.x up to around 3.9 is good and works fine with regard to the goal for generating the .project eclipse files, believe there's also a mojo (a maven plugin) for generating intelliJ IDEA project files as well as others. If you're using Flex 4 you can compile with the latest flexmojos 4.0RC2 but it appears to me that the goal for generating flex/flashbuilder project properties is now gone (I'm not sure if this is because it's been replaced by another plugin altogether or what the deal is). However building with maven and flexmojos does fulfill all of your goals above (we also use it for building our service layer, so in a single mvn clean install we get a jar packed in a war packed in an ear with everything configured and a swf, that part is really nice). Also you can do continuous integration using bamboo (or simply write your own script that is triggered from a cron job or in windows as a batch file executed with a scheduled task if you don't have a *nix server around). Let me know if you'd like any more details or if I missed something major.
Shaun
I have been using Hudson, now Jenkins, with Ant for Flex automated builds and FlexUnit testing. Jenkins has some really useful plugins for integration with eclipse (and hence, FDT or FlashBuilder), Jira, SVN, Git etc., and it's free. Also, you can integrate the Ant build into Maven scripts, so I've found this to be a good and flexible solution for all purposes I've come across so far.
The Flex SDK comes with Ant tasks, and writing even elaborate Ant build scripts is quite easy - in fact, I'd been using Ant locally before, and I could reuse my existing scripts with only a few added extra compiler options for FlexUnit tasks.
However, it took a while to set up the system correctly for unit testing, because I'm running a headless server on Linux, and that implicates a rather complicated environment for ActionScript tests, because they run only in Flash Player. This, of course, is true for all CI scenarios using FlexUnit, regardless of which server you use.
Here's what I've learned:
FlexUnit needs a standalone debugger version of Flash Player installed, but Adobe only distributes binaries for the standard version on Linux. Therefore, compiling from source was necessary, and since my server system is stripped down to the bare necessities, it took some effort to install all the correct dependencies and get them to work.
The Flash Player needs hardware to run correctly: It uses graphics, therefore it needs a graphics card, and sounds, therefore it needs a sound card. On my headless server, this meant I had to install a VNC host to get it to run at all, and I had to eliminate any tests using sounds (those will now only run on local machines). If anyone ever comes across a working sound card emulation for openSuSE that I could use with the VNC client - you'll be my hero forever!
If you've set asynchronous timeouts in your unit tests, and/or you need to use setTimeout() to send delayed procedure calls, make sure the intervals aren't too short - I've had problems with tests that ran fine on any local machine, but broke the build on the CI server, because the Flash Player is considerably slower on the VNC client than on an actual graphics card.
I've also found this last issue to be a healthy lesson: Criteria for unit tests should not be based on assumptions about the system's performance, or at least be tolerant enough to succeed even on a slow machine.
I often find the quote "InstallUtil.exe" is an ugly pattern or "Don't use InstallUtil.exe" and that I should use native WIX or Installation package patterns and I still don't understood why.
I stepped away from using InstallUtil to install a .NET service as I finally learnt that writing registry keys for such an action should be an un-install-able action - and I've come to terms with this as correct.
As I've been working through my WIX installer for a relatively complex product, I have found myself in need of creating or updating SQL Server databases, creating or updating IIS Applications and finally updating or creating configuration files.
Each of my components (features) are optional, but they all share the same configuration file. As my product uses unity, its important to note that this library contains strong support for reading/updating/removing components from the Unity Configuration block, therefore it seems fairly smart to me that I should take advantages of these blocks via Installation Components (i.e. InstallUtil) to create or update my configuration file at installation time.
Just to be clear here, my installer does not natively contain a configuration file for my application: at installation time, the installer has no idea as to the shape of it as its based on the features selected. Surely I should be embedding this knowledge into each of the modules that are to be deployed and not in the remit of the installer which is now a completely independent project? Wouldn't this break O-O principals even if we are talking about installation?
I'd really appreciate some guidance as to whether this is good practise or not? Am I reading 'InstallUtil' is bad for installing services, or is it that using 'InstallUtil' is bad full-stop? If so, what are my options for smart updating of configuration files?
The main reason for avoiding InstallUtil is that it runs outside of the installation transaction, so Windows Installer cannot keep track of what it's done.
I have used InstallUtil on a few occasions, when I just couldn't get Wix to do what I needed and didn't have time to write a custom action. In this case I called the InstallUtilLib version as I feel this is a cleaner approach.
I used the this blog as a guide as to how to achieve this.
Our group uses Visual Sourcesafe as a file repository for all of our "content" (HTML, CSS, Javascript, JSP). None of it requires building or compilation but we would like to automate the copying of it to a Unix dev server upon check-in.
I have used Cruisecontrol.NET in the past for CI at other companies but it was for .NET. What would be the easiest way to achieve our current requirements? Would using CruiseControl.NET be overkill or even a good idea? Thanks in advance.
-Sean
This sounds like overkill for a CI tool.
Visual SourceSafe and other version control systems should have hooks allowing you to automate a simple file copy operation.
From http://msdn.microsoft.com/en-us/library/aa302175.aspx
Use events, such as OnBeforeCheckout
or OnAfterCheckIn to automate your
process.
Whether this makes sense for you depends on a couple of factors. If you are talking about a large, geographically team with only change based deployment then yes, those are valid concerns. If you only have a few local developers and you deploy the world on each copy operation, then no, I don't think you'd need a CI tool.
This is not to say other reasons may influence you to use a CI tool, testing for instance. Your problem might also be solved by running a polling script on the Unix box to sync the source control with the dev server. I guess the main point is, if you are deploying all non-compiled software, why do you have a separate source control and dev server? You're deployment can be done by a source control tool. If it is only for backup, there are plenty of existing solutions for that problem.
Sean,
Our AnthillPro customers do this kind of thing pretty frequently (and we even do it internally when new content is committed for our website). It's a really good idea, totally appropriate for a CI tool, and you can get quality feedback if you wire in some automated functional / regression tests.
Eric
You could try using Hudson http://hudson-ci.org/
It is easy to configure, is completely GUI (unless you want to go into the details), and has a plugin for Visual Sourcecafe http://wiki.hudson-ci.org/display/HUDSON/Visual+SourceSafe+Plugin
While CI would probably be overkill for what you are trying to do, since Hudson is all GUI and easy to use, you would not spend a lot of time just trying to configure it.
Hudson also has plugins for copying stuff over to other systems, and so it would be easy to deploy your content to another system.
If you are worried about the process, get in touch with a hosted CI provider, such as MikeCI, a quick message on their support board will get you the answer. I don't see why triggering a "build" can't be replaced with copy and paste!