I am currently fetching the JS SDK from "https://www.gstatic.com/firebasejs/5.4.0/firebase.js". I want to make sure that my setup that doesn't change. Can I assume that Firebase would not change this file (or any version for that matter) without changing the filename?
Never assume that internal files won't change without changing the file name. There is a good chance that methods inside that file may indeed get changed to match with current changes or upgrades in technologies. Usually, though, major developers will do their best to insure the changes will not break anything in legacy files.
Firebase practices semantic versioning. This means that minor versions are backwards compatible, while major versions may contain breaking changes.
So version 5.4 should be drop in compatible with all 5.x versions.
But if you upgrade from a 4.x or lower version, you may have to make changes.
Whether this is actually needed depends on what products you use, and the changes to those products between the versions. The older the SDK you're upgrading from, and the larger the number of products you use, the higher the chance that you'll need to upgrade.
If you want to check what has changed, check the detailed release notes here: https://firebase.google.com/support/release-notes/js
Related
Am I correct in observing that Corda 1.0 is using Kotlin plugin 1.1.4? Just out of interest I tried to use 1.1.51 and ran into defaultWhiteList loading issues...although I'm not entirely sure why tbh...suspect classpath loading issues on the ServiceLoader.load in DefaultKryonCustomizer?? Anyway, when I revert to 1.1.1 (am still on M13) all is well again.
Just wanted to gain some understanding around why an inadvertent upgrade of the Kotlin plugin to 1.1.51 would cause issues with the serialisation default whitelist loading?
Thanks
A somewhat non-answer, but I'll try anyway: As we see the kotlin language mature and as Corda uses quite a wide feature set of what's available in kotlin, it doesn't surprise me that sometimes the frequently published newer versions of Kotlin don't work with older versions of Corda - especially if they make some internal changes to objects then I'm not surprised we see kryo serialisation issues. We publish the recommended / supported version of kotlin in the constants.properties file which, for release 1, is as you've correctly pointed out, 1.1.4 (which can be confirmed here: https://github.com/corda/corda/blob/e564edaa572a011869d692b05518113632363216/constants.properties ).
It does look as if we have updated this for the forthcoming v2 release to 1.1.50 if that helps. It may be a little late in the day to bump this to 1.1.51 though (a fair amount of testing and QA has already been performed).
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.
As an owner of Flash Builder 4.6 I'm struggling with 2 problems in my web application:
XML parsing makes the whole application sluggish
Russian input in TextInput doesn't work with Opera
I wonder, if there is a new Flex SDK available for download, where some fixes might have been integrated since the Flash Builder 4.6 release several months ago.
So I have downloaded the "Flex SDK version 4.6.0.23201 is the latest production quality release" and installed it:
However this seems to be a version, which differs very little from the stock Flex SDK included with Flash Builder 4.6 originally.
My questions is: is there some good (i.e. fresh, but also tested/stable) source for Flex SDK, which would be suitable for Flash Builder 4.6?
Maybe I can check out the source from some repository and build it myself (how, please?).
Does Apache offer anything, since they are the new owners?
UPDATE:
I've checked out Apache's Flex with
svn co https://svn.apache.org/repos/asf/incubator/flex/trunk flex
(and have yet to figure out, how to build it) - isn't it newer and better?
is there some good (i.e. fresh, but also tested/stable) source for
Flex SDK, which would be suitable for Flash Builder 4.6?
Yes, that would be Adobe. I am not aware of any updates to Flex 4.6 since it's release late last November. It's only been three months. I believe the bulk of Adobe's work around Flex has been getting legal approval to submit Flex to Apache. They are getting that slowly.
You can download the source for the Adobe Flex SDK from opensource.adobe.com. Read this for info on getting the source from the Adobe SVN repository.
Does Apache offer anything, since they are the new owners?
The Apache project is still formally waiting for donations from Adobe, including their testing suite. But, some code is submitted from Adobe. A few people have submitted some new components, and there has been work done around localization. The Apache project does not have a formal release yet.
You should be able to get the Apache Source from SVN as an anonymous user. The trunk includes the framework dump from Adobe; but I haven't delved in myself. I know people have successfully built the Flex SDK from the Apache trunk. Here are some instructions on how to do it with IntelliJ
I should add that I'm not sure if updating the SDK will solve any XML parsing issues you have. But, it's tough to say for sure since you went into no details on what those issues are. My mobile game uses a 30K line, 1MB XML file for the level definitions and it has no problems parsing it effeciently.
Flex SDK sources
You can find the latest source code through the Flex Apache incubator page and use Subversion to check it out. However since the migration of the Flex SDK from Adobe to the Apache foundation is still very much in progress, I sincerely doubt that there would already be significant changes that would fix your issues.
The actual issues
XML parsing makes the whole application sluggish
XML parsing is a pure ActionScript matter and has nothing to do with Flex. It is closely related to how the Flash VM works, which is still closed property of Adobe. I don't think it is subject to change any time soon, mostly because I've heard very little complaints about its performance and the E4X language is one of the most powerfull around. If you're having performance issues better have a look at your architecture or work with AS model objects instead of XML.
Russian input in TextInput doesn't work with Opera
This is either related to the Flash VM (see above) or to the Text Layout Framework, which is "open-source", but still in the hands of Adobe. Whether it should also be contributed to Apache Flex is still being discussed. In both cases very little will change in the short future, so I think you'll have to try another approach.
Are you sure it has anything to do with the SDK? If the problem of cyrillic chars exists only in Opera - then it's more like a problem of Opera and its Flash-plugin.
This is what you get with Flex SDK 4.5 and Opera 11.61:
There might be another problem if you're using some font that doesn't have the cyrillic char subset (e.g. not using the default font). But if that were it, it would affect all browsers, not just Opera.
привет землякам!
I have to upgrade website running very old version of Drupal (cannot even find out which version is that, but I guess it is even before 5) to the newest one? Is that possible? If yes, how to approach this?
The Drupal web site makes it clear that you cannot skip major versions when doing version upgrades.
See this page: http://drupal.org/upgrade/
(it talks about not being able to skip from v5 to v7; it doesn't even mention v4!)
So if you do manage to upgrade your site all the way from v4.x to v7, one thing is for certain - it's going to be a long-winded process.
The other thing that is going to be a major issue for you is that the Drupal module ecosystem has changed radically in the space of time between v4.x and v7. Many modules that you'll be using in v4 will be either unsupported in later versions, or not have an upgrade path, so you may have a lot of manual hacking to do.
On the flip side, there are likely to be newer modules that can do things in recent versions of Drupal which were not possible in older version or were done in a very different way, and you may find yourself wanting to use some of those modules instead of ones you've got in place. Again, lots of manual work I forsee for you.
In summary, I would suggest that upgrading from such a long way back to the current version is going to be extremely difficult. You may find it easier to start again from scratch and rebuild everything. I'm sure you could get some data imported from the old site to maintain continuity.
One further thing I would add is that this isn't a Drupal-specific problem, so please don't blame the Drupal developers if you struggle with this upgrade - you'll get this issue with virtually any software you run if you don't keep it up-to-date. Try upgrading a Windows95 machine to Windows Vista and you'll see what I mean.
It would be possible, but could be very hard.
You would need to go from 4 to 5, then 5 to 6, and finally 6 to 7. You will have to make sure that your data is still intact along each upgrade and back up your database. Update any contributed modules and check if any have been deprecated along the way and find suitable replacements if possible.
Depending on your site, if it is just the content and you are not concerned with losing url aliases, taxonomy terms, etc. then trying to export/import your raw data directly into a fresh drupal 7 install might be easier.
Edit: You would also need to upgrade any custom themes and modules drastically.
I do not envy your task, as you will need to learn the changes from D4 to D5 only to later discard this knowledge as you learn the changes to become D6 compatible and then discard that knowledge to become D7 compatible.
As you said you do not really care about losing taxonomy terms or extras, you might want to try http://drupal.org/project/import_html or a similar module to scrape your website (though it is not actually static) and convert it automagically into nodes. That module is not currently available in D7, but would get you from D4 to D6.
The key thing to remember is frequently backup your database in case anything goes wrong or you want to try different upgrade paths.
It is doubtful that many contributed modules you are using would survive the upgrade, unless there is a release for each of versions 4, 5, 6, and 7. I agree with #brian_d, the best course of action may be to export your content and import into a fresh Drupal 7 site.
The general procedure for updating:
Assuming you are on version 4.7.x of Drupal:
Update Drupal and any contributed modules you can to the latest release for 4.7.x, in case there were schema changes
Disable contributed modules
Update Drupal to the latest version of 5.x
Update and re-enable modules/themes to the latest release for 5.x
Repeat steps 2-4 for 5.x to 6.x and again for 6.x to 7.x
I've been using Drupal since 4.x. During that time I've had to upgrade numerous times. Mostly I've had good success using the standard upgrade process. However, I've had to do several upgrades manually because of one issue or another. This was basically a Copy and Paste upgrade.
To read more about the Copy and Paste Upgrade go here: Upgrading Drupal by Copy and Paste.
I want to serve a lot of big files in a Plone site. By big files I mean around 5MB (music) and a lot of them. I've already do it straight to the ZODB, not a good idea. I'm running Plone 3.1.1 and Zope 2.10.6.
Zodb blob support is the best, most integrated way to deal with large files. Big files are stored transparently on the filesytem instead of in the zodb object database. "Transparently" in this case means that you won't notice it in your actual programming work after initial configuration.
The blob functionality has been backported to current (halfway 2008) zope versions and can be used in plone 3. Use plone.app.blob in your project for this: http://plone.org/products/plone.app.blob.
Yeah, you shouldn't use anything else than the ZODB BLOB support at this point. It works fine with the 3.x series of releases.
More information in ticket #6805
— Alexander Limi, Plone co-founder
Clarifying, to the best of my knowledge:
from various candidate technologies in a PLIP (Plone Immprovement Proposal), plone.app.blob is the lead contender with widespread support
-- for exceptional use cases, we sometimes find something other than BLOBs recommended
4.0 is currently the most likely milestone for plone.app.blob to become a product within Plone core
in the meantime plone.app.blob is a recommended add-on product for current 3.x versions of Plone
-- for use cases that suggest BLOB-like technologies.
As you may already know, the long-term solution for this is supposed to be the ZODB BLOB support. Ticket 6805 is probably the most authorative source on this. Unfortunately, the milestone is set to 4.0, and running it in production on an older release is perhaps not a good solution.
There has, historically, existed a lot of Plone products for storing files externally, keeping only metadata in the ZODB. I have tried several of them, and from my experience, there is not a single one that works well with current Plone/Zope releases. Don't trust me on this, though, I have not tried any products of this type the last year or so.
Personally, I would go for a solution that is as simple as possible and doesn't involve Plone more than neccesary. Storing the music files on disk, serving them directly from apache/whatever web server you use, keeping only metadata in Plone - in a product you write yourself, will give you a robust solution with good performance. That is, your product should produce links to a path on your web server where the music files are available.
If you require authorization for download of the music files and assuming that you run lighthttpd or apache in front of your Zope, looking at a solution based on X-sendfile is probably the best option. With X-sendfile, you keep the files on disk, and add a header (X-sendfile) to the response when a music file should be sent to the client browser. The web server will pick this header up and send the file to the client, without Plone being involved.
Some pointers:
http://tn123.ath.cx/mod_xsendfile/ (The apache module)
http://john.guen.in/past/2007/4/17/send_files_faster_with_xsendfile/ (Ruby example)
I have plone.app.blob installed on some low-traffic sites and installable (ready to roll, if you like) for my busier production sites in the same instance.
There's the 4.0 milestone but I'll certainly review (and probably click the install button for plone.app.blob on my production sites) around 3.4 time.
A couple of references:
http://n2.nabble.com/PLIPs-I%27d-love-to-see-for-Plone-3.3-tp1123218p1130015.html
http://dev.plone.org/plone/ticket/8629#comment:2 highlight
… 3.4, when we'll probably have blob filestorage specification
support added to plone.recipe.zeoserver and zope2instance. That will
give us a standard location for whatever owner/permission fixups the
installers need to make.
In context: I'm playing roughly with plone.app.blob and a very mixed bag of other add-on products with versions 3.1.7 and 3.2a1 of Plone based on standard and experimental installers. In these environments, without me treating things with kid gloves, Plone sies behave remarkably well and when (as expected) experiments lead to oddities, the support from the community is paced and proper.