is There a way to use OpenLayers on Flex?
By now I've found Open-Scales project, but it is in development (not fully functional).
We have recently released OpenScales 1.1 which has a lot of improvements and bugfixes compared to 1.0 beta release. There is a demo available on previous link.
OpenScales API have been designed to be quite close of OpenLayers one.
Since the beginning, the codebase has been extensively modified and
improved. Nevertheless, even if OpenScales API is not strictly
equivalent to OpenLayers one, if you have ever developed on
OpenLayers, you will find OpenScales API quite easy to understand.
OpenLayers is a pure JavaScript framework and I do not think that anyone has written a Flex wrapper for it. So the short answer is either "no" or "not easily".
That said, there are other Flex mapping clients available, depending on your needs.
ArcGIS Server Flex API
Google Maps API
Yahoo! Maps API
I don't use Flex, so I am not qualified to speak to the merits of each API but hopefully it can get you started. Good luck!
OpenScales is an LGPL ActionScript3 port of Openlayers. It might be what you are looking for.
OpenScales is really good, especially with the 1.2 release. However, it is a pretty small project and the support is not so good, so you're pretty much on your own if you get stuck.
Related
It has so-called JS client. But all the docs or demos are written from the point of Python developer.
Does bokeh has standalone, non-python JavaScript API, and is it used by anyone in non-python environments?
Does bokeh has standalone, non-python JavaScript API
As of late 2019: Somewhat! (See below for more context)
and is it used by anyone in non-python environments?
Yes, definitely, though pure-BokehJS usage levels are still low compared to Python APIs. Improving the JS story is a 2020 goal.
A little history
The Bokeh project was started in 2012 with the explicit goal of providing Python developers a way to publish interactive visualizations in the web, without themselves having to get into "web tech", i.e. JavaScript. As such, the BokehJS library (which has always existed) was originally mostly a largely undocumented implementation detail. It didn't really help that the Bokeh developers themselves were not JS experts at the time. (Some of us still are not!)
As things progressed, and features like CustomJS callbacks and the ability to make custom extensions were added, the BokehJS side of things became more and more publicly exposed. That said, until fairly recently, BokehJS development has been very fast and furious and we were not in any position to provide guarantees around core API stability or expend resources on documentation that would likely be out of date very quickly. As two examples, in the last year BokehJS was completely re-written in TypeScript, which rendered any old CoffeeScript extensions or callbacks deprecated. Additionally the entire layout system was re-vamped to afford much higher performance.
Current status
For some time, there has been a fairly stable "high level" API for BokehJS, and you can find details of that in the Developing with JavaScript chapter of the users guide. Additionally, all the low level "models" and their properties are 100% aligned up between Python and JS, so the Python Reference Guide actually has all the information you might need to use models on the JS side as well.
We are very interested in improving BokehJS for pure JS usage in the coming year. We have been getting some very helpful issues from folks actually using BokehJS directly. Some major hurdles will be overcome with the upcoming 2.0 release, but there will still be work to do to really provide a great user-experience for JS devs. This is actually a fantastic opportunity for any interested JS devs to have a big impact by offering their input, advice, and collaboration. Anyone so interested should head over to the Bokeh project Discourse.
So I'm new to node.js, javascript frameworks, and meteor.com. I'm trying to learn how to build social networks, and I'm naive/struggling to understand why Meteor.js (meteor.com) wouldn't be able to do all the great things you see now that twitter, facebook, instagram are doing?
There's the comet technology between client/server, authentication configs, asynchronous coding for scaling and performance, and built on top of node.js.
I'm trying to learn more about long polling, comet, gridFS or how files are stored, and in general things like replication sets, and sharding to help with performance (esp since Redhat has this openshift platform that we can build our own private clouds with).
I have some computer science background, but it seems like magic, so what am I missing? If you all could think of a few buzz words that make a social network tick that Meteor.js doesn't support, what would it be?
I hear things about parallel and concurrency (webworkers fixes that in part, no?), websockets, that high level languages like python or java are better off supporting. There's only one to learn my answers, and thats by doing, but thought someone could sway me one way or the other via this thread. Thanks!
This question encompasses a really broad idea and just focusing on using meteor alone would solve this issue. Here are a few points to consider:
I don't think this framework would be a good starting point to learn long-polling, gridFS, etc etc. Meteor aims to be a framework that tends to be more of an ecosystem of packages e.g. you can certainly roll your own aformentioned strategies -- however for dynamic updates, Meteor uses its own Data Delivery Protocol (DDP) supported/implemented by (surprise) a good bunch of core packages such as Spark.
Parallel processing and concurrency can be better off done using other languages, but why not with? Since Meteor is largely based on node.js, and node.js is really good with the aforementioned stuff plus it can play very well with other languages so you could integrate smoothly. Meteor doesn't really require you purely rely on it, as other languages would say the same thing. It's all in the general engineering / planning for your project. There are already lots of really good stuff out there that rely on Meteor, join in! don't be afraid. It all boils down to planning (and the courage/perseverance to pull it off, of course).
Right now, we cannot tell if Meteor would be incapable of the usual great stuff by gigantic websites. Sure, we can do live updates, (its own kind of) publish/subscribe patterns, and powerful stuff to boost development (look at the seven core concepts of meteor to best understand this). It is not impossible to replicate what is already out there, really. We can only say it with uncertainty at the moment mainly because.. (see next point)
The framework is so young! it's still at 0.6.x at the time of writing. Please take time to look at the Meteor Roadmap to see how things are going in terms of broader support for persistence/databases, performance considerations, and the official DDP specification.
I hope I have answered your enquiry (and more, I hope). I'm really excited for meteor myself as it could easily be the next big thing. We have a couple of (for-)production projects using Meteor as well, so you're getting direct insight from a person who has done quite a bit of hacking (and tons of research and first-hand experience) in Meteor. Not that i'm saying i'm an expert or so, it's just so much fun to work with Meteor and i'm totally not kidding you.
Hope this helps!
P.S.: Fair warning though, resources and documentation is really sparse at this point. I try to contribute to the community as much as I can about it (one of my starting points is here, on SO).
I've just discovered TideSDK and it seems to be a really great tool, but I have one requirement : I need to use some native code (for managing USB devices for example) and so I need communication between this native code and the web app, is such a thing possible with TideSDK?
Yes, working with native code in TideSDK is possible. Our SDK is modular and we have been reorganizing the code structurally to make it easier to do the sort of thing you want. At a modular level, you will be contending with support for multiple platforms typically.
A module should extend to all platforms that you are supporting. We expect to have documentation to help developers (familiar with native code) to better understand the SDK. This should include some module boilerplate to help you get started. At this point, we have yet to prepare this more detailed documentation. We have much to do and sometimes progress seems slow despite all the great efforts going into TideSDK.
TideSDK is a large and complex SDK but don't let this frighten you off. It is extensible and we will be shining light on this soon with module development guides. It would be cool to talk more on IRC about this with you so feel free to drop by at any time. Perhaps the functionality you are speaking of is of general use ie. to extend the APIs for everyone.
There are possibilities to work together with the core developers of TideSDK on modules and to contribute to this great open source project. Other possibilities also include sponsoring module development if this something that you need more immediately for a project. Hope this helps.
I want to throw together a .net website as an interface to a subsystem I manage.
I'm planning to use ASP.net (on .net 2.0) because this is the shop's standard.
I would like to use an ORM because I was playing with Django a little bit ago and realize the time saver and code simplifier it was. I realize I may not get the time saving aspect because of the setup but I think it should make maintenance easier.
Can someone recommend a stable, very easy to learn/setup ORM product that works with ASP.NET 2.0. I prefer open source, but as long as the product is free it's fine.
Because learning something is dependent on the learner I want to share that I'm an experienced developer. I use a lot of languages and generally learn quickly with good material.
I'd recommend Castle Active Record.
It's built ontop of NHibernate, which is a pretty popular one, but Castle's AR is faster to get off the ground with in my opinion.
I used it on my last ASP.NET project so can vouch for usefulness there. :)
Edit - Here's a quick link to "Getting started".
I recommend NHibernate. It is full featured, very mature and (in my experience) quite stable. Take a look at the summer of nhibernate screencasts (also free) and you'll have enough knowledge to get up and running in no time!
Is there any alternative image manipulation library for .net? I would prefer something that is managed and open source.
I ask this because of two reasons:
I have encountered hard to debug GDI+ errors with System.Drawing in the past
I have read that using System.Drawing in asp.net web applications is not 100% supported.
Thanks!
edit: clarification, I know that System.Drawing can work asp.net web apps - I have used it in the past. I really just wonder if there are any managed image manipulation libraries for .net :)
You should look into the WPF Imaging libraries shipped with .NET 3.0. They're optimized and robust (used to run Aero, so you know they're efficient). They don't depend on the WPF dispatcher, are easily extensible, and officially supported. What more could you want?
I don't know of any fully-managed 2D drawing libraries that are either free or open-source (there appears to be a few commercially available, but OSS is the way to go). However, you might look into the Mono bindings to Cairo.
Cairo is a platform independent 2D drawing API. You can find more information about it at the Cairo homepage. The Cairo Wikipedia page also has some good info.
Cairo is also used fairly widely in the Open Source world, which to me says something about its robustness. Mozilla, Webkit, and Mono all use it, among others. Ironically, Mono actually uses it to back their System.Drawing implementation... go figure.
There might also be a way to use Mono's System.Drawing implementation as a drop-in replacement for the Microsoft implementation, though I'm not sure how or if that would even work. I would probably start by replacing the System.Drawing.dll reference with Mono's version, and then try to deal with any errors.
Anecdotal evidence #1: I have used GDI+ for on-the-fly image creation within ASP.NET with no problems. I'm not sure what the problems would even be.
With respect to (1), most of the hard to debug errors are due to not closing open handles (Dispose() in managed-land). I'm curious where you heard (2).