I've been looking at options for persistence when using RxSwift and Realm was looking attractive due to it's relative simplicity and the availability of some extensions in the community repo.
Unfortunately although I can get Realm and RxSwift working nicely in Xcode 8b6, things of seriously wrong as soon as you try to connect them together as RxRealm does not currently compile (there seems to be more going wrong with it than the Grand Renaming as far as I can tell).
Is there a workaround that is reliable? I can't believe for a moment that there isn't, I just can't find a resource at present. I was thinking of converting the Result object into an Set or Array and making this Observable but. I'm not sure if the contents (Realm Objects) are going to be handled correctly. Knowing my luck, I suspect not!
There's a Pull Request towards the RxRealm project adding Swift 3 support: https://github.com/RxSwiftCommunity/RxRealm/pull/26
I suggest you try using that.
More generally, targeting an Xcode beta will by definition give you a less stable software ecosystem, since no one is submitting apps with that and it's a moving target (often with weekly breaking changes). So if you want stable software, use stable tools. Realm and RxRealm both support Swift 2.2 quite well, so using that will give you the best experience.
Related
The title more or less says it all.
From what digging I've managed to do, the answer to if this is possible seems to be "no", but the whole GNU build tools platform is something I know very little about, so I could easily be missing some detail.
Context
I'm trying to set up an as-hermetic-as-I-can build of something that needs gnutls and I'm trying to minimize the list of things that need to be installed prior to the build (i.e. don't use the thing, or build the thing from source). One attribute of the build process is that the only accessible build artifact from gnutls will the absolute minimum needed to call and link it in (more or less the .a files and includes directory). So even if documentation is generated, it won't ever be accessible. As such, a dependency on a doc generation tool is something I strongly want to avoid.
What I've dug up
It seems, based on this merge-request comment, that gnutls requires that that gtkdocize be installed regardless of if it will be used. The context there seems to imply that this is by design to make the gnutls development process (as opposed to the use of gnutls) less error prone. (I'm really hoping I'm misreading things or that something has changed since then.)
This seems like an odd choice as it take a problem only experienced by developers and solves it by requiring anyone who wants to build the library (even as a transitive dependency) to assume that dependency even if they will actively suppress using it. (This seems particularly odd given this expands the potential attack surface for a security project.)
Chrome is on the verge of definitly break compatability with NPAPI, and IE breaking with ActiveX the future of Java Applets is dark. Currenty we actively use a secure applet for out client organizations that enables their users to upload a bunch of files from their file system to our servers with the click of a button. The applet has full access to any configured drive, including network drives.
With the imminent death of the applet this functionality is going to be lost if we don't find an alternative. I have already tried to explore different solutions, including the chrome FileSystem API but that is currently only available for Chrome (http://caniuse.com/#feat=filesystem) and has limited access.
Does anybody know about an alternative to keep supporting the much appreciated functionality? Unfortunately we are obligated to support all browser down to IE8.
I've written a post about this here.
Once Google Chrome was the first to announce that they won’t be supporting NPAPI anymore, they were also the first to provide a new architecture in order to rewrite your code to work on their browser. You can take a look on Native Messaging, which “can exchange messages with native applications using an API that is similar to the other message passing APIs”. The problem is that this approach only works on Chrome, is not something that you can adapt to other browsers.
A more useful approach is FireBreath, a browser plugin in a post NPAPI world. Check the words below from one buddy of the project:
“FireBreath 2 will allow you to write a plugin that works in NPAPI, ActiveX, or through Native Messaging; it’s getting close to ready to go into beta. It doesn’t have any kind of real drawing support, but would work for what you describe. The install process is a bit of a pain, but it works. The FireWyrm protocol that the native messaging component uses could be used with any connection that allows passing text data; it should be possible to make it work with js-ctypes on firefox or plausibly WEB-RTC or even CORS AJAX in some way. For now the only thing we needed to solve was Chrome, but we did it in a way that should be pretty portable to other technologies.”
In light of the answer provided by Uly Marins I have researched the options suggested. Unfortunately these options weren't viable for our application, because the mayority of our users do not have sufficient rights to install third party plugins. Additionally the API is still in Beta which won't do any good in a stable production environment.
The main problem we wanted to solve was the abbility to delete files from the accessed folders. It seemed like one of the mayor goals of the removal of the NPAPI support was exactly to prevent this kind of possibility. Therefore we needed to reduce our goals to a simple solution that was still acceptable for our users, with the additional training on how to clear the selected folder manually (because most of our users are almost computer illiterate and needed to access network folders).
Long answer short. The requested solution is just not possible anymore and had to be replaced by a simpler solution and additional training.
Being that Meteor on Windows does not currently support Velocity/Jasmine, I would like to use a cloud-based solution for running Meteor with Velocity. But so far I have not had success. I have tried Nitrous, Codeanywhere, Koding, and Cloud9.
I also use the Meteor Windows Preview and the same issue. See my SO: Easiest way to create mobile apps on official Meteor for Windows
I had the additional constraint that I want to compile Mobile Apps which is currently not supported by the Windows Preview.
I've not had success with cloud-based solutions either beyond very basic test apps. The whole chain is just too fragile, there's often something you need to configure that you can't get at in a cloud solution. Basically, your options are:
Vagrant
Dual-boot (thanks #sbking)
Buy a Mac
I would recommend 3 because it will save you time (and therefore money). The first 2 are fiddly, just adding more sys admin work when we should all be coding :)
ALTERNATIVELY
Switch testing tools to Laika. See related SO: Laika vs Velocity on meteor TDD
Laika (apparently) still works for the moment, even though it is no longer officially supported. I will be using it for my current project in the next few weeks.
I'd be really interested to hear what solution you go for.
At the risk of offering you a pocket-knife when you want a power-tool, there is a meteor package, jasmine-green, that does not require Velocity and therefore works well with Cloud9. While this means that you would not have the full capabilities of a velocity-based jasmine or mocha package, it is a lot better than nothing. Just type:
meteor add fongandrew:jasmine-green
It might be a stopgap while you find a better long-run solution.
We are using Adobe LCDS 2.1 and thinking of Upgrading it to a higher version.. can someone tell me a brief Comparison of the LCDS versions available (3.1 , 4.1....) ????
The last version is 3.1 You need to read the documents from this url in order to understand what are the new features (the release is good but is not enough), and after that it would be good to try building a prototype (if you plan to use the data modeling for example) to see how they will fit into your current architecture.
I wouldn't do any upgrade unless there is a business reason (bugs, poor performance, luck of productivity) - for any product.
I don't know why you'd need a comparison for 'all versions' if you can only purchase the latest one. I suggest you look at the latest version's whitepaper so that you can see what's been added. The biggest thing IMO is better integration for all clients, different messaging protocols and well as much needed bug fixes (I remember 2.1 had some fairly obvious bugs).
Looks like the choice is "should we upgrade or not?"
I'd say it may also be worth considering what you're doing with LCDS -- if you're only using it for things like Flash Remoting, is it possible that you could go the other route and 'downgrade' the the open source BlazeDS? It has a lot fewer features, but might do what you need, and be a lot cheaper.
Here's a comparison of BlazeDS to LCDS ES2: http://www.adobe.com/products/livecycle/dataservices/compare.html
I'm not familiar with prior releases of LCDS, so I can't offer any better advice about comparing versions than the previous respondents. Basically: Check the release notes =)
I've been bitten in the past by Page.RegisterClientScriptBlock-registered JS not being emitted in a stable order from machine to machine in the bad old .Net 1.1 days. Now, I'm writing a set of user controls that use <asp:ScriptManager/> to reference JS, and although I haven't had any problems so far - order always seems to be conserved between <asp:ScriptReference> tags - I'm feeling a bit shy about it. MSDN seems silent on the topic, and various bloggers seem to indicate ordering is stable in .Net 2.0+, but I haven't found any definitive reference.
Does one exist? Is the order of inclusion of scripts I observe on my development machine guaranteed to be the one I'll see in all other contexts the webapp runs?
Further analysis concludes that the answer is that they are, at least in my particular production and development environments.