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.
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.
Not sure if this is the right place to ask this kind of questions because it is also a bit personal favor but what are your experiences with Xamarin UITest and/or Appium. Until now I only had experience with Appium but for our new project we maybe want to use Xamarin UITest.
Wrong answer, with Xamari UI Test framewor you can automate Progressive Mobile Apps, Hybrid apps a Native Apps, on Android and IOS
Some samples here:
[https://www.zuehlke.com/blog/en/mobile-ui-testing/][1]
We have a React Native app that we are currently testing with Xamarin UI Test, and I've spent quite a while comparing these test frameworks. It looks like our team is going to switch to Appium now. Here is what I like about Appium:
Much better documentation, more resources online
More features (which allows you to automate more stuff)
Runs slightly faster on Android (30% faster maybe), not seeing almost any difference with iOS
Bigger, more active community, less chance of framework becoming deprecated
Based on our experience it's more reliable. With Xamarin we kept getting "device port 27753 in use" or smth like that which we couldn't resolve.
More "device farm" options to run tests on. This is very important for us. With Xamarin the only options I've found are BitBar (flakey, adds about 5 minutes overhead to test runs) and Xamarin Test Cloud (expensive). With Appium there are more options (SauceLabs seems to be working great, we are only starting to use it though)
Allows you to choose from a lot of programming languages (our team is most comfortable with TypeScript)
Client-server architecture which allows test code to run on-premises (might not be a benefit to many teams, but it is to us), so the test code is able to access our internal APIs thanks to this
Firstly, SO is usually not the right place for such questions as such questions usually get closed as off-topic and primarily opinion based. Luckily, xamarin.uitest is a very unpopular tag, hence, your question survived :)
For what Xamarin.UITest does, its actually not bad. The biggest issue to consider is that Xamarin.UITest requires your app to be written using Xamarin.Forms and for me, personally, this is the biggest drawback.
Other issues, that I've encountered:
Scrolling is terribly slow
Limited API (Only basic UI properties can be evaluated, see here)
Minimal differences betqeen Android and iOS which can become really annoying, depending on your use case
Other than that, Xamarin.UITest is a pretty solid UI-testframework and if your app is written using Xamarin.Forms, I would recommend you to use Xamarin.UITest.
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 am thinking about using PlayN to manage "common code" in Java and use PlayN to generate iOS, Android, and HTML native versions of the common code.
I figure I could then use the playn-generated native code and link with actual platform specific code (such as UI).
In other words,
Common Code libs in Java-> PlayN -> Native Commond Code Libs -> Link with Native App
Is the use of Play for the above workflow/pipeline appropriate? Any challenges?
Thank-you...
Firstly, you have to specify what you mean by "native" code for the different platforms.
On Android, your java files are specifically compiled/prepared for dalvik. So they are already "native" of a fashion, no work needed to be done here. If you want to get C/C++ native code for Android using the NDK, you're out of luck. PlayN doesn't do this and this is a hard problem (going from Java to C++)
If you take a look at the Maven modular layout of how PlayN is intended to be used, it isn't difficult to define a Factory interface in the common code and pass in a platform specific implementation for each module. It's no big deal to support Android specific functionality this way.
For the HTML version, you can use HTML libraries no problem using JNI, although really garnering specific functionality of the browser I'd imagined of limited value compared to what PlayN has already exposed. The one thing that is useful is text/keyboard input, although I'd recommend triplePlay https://github.com/threerings/tripleplay UI library as they've solved this, and it's an active project.
As for iOS, this might be more complicated as the iOS module is a bit of a hack where the compiled Java classes are run through an JVM runtime for .net (IKVM) and then uses the Monotouch tools to compile the whole thing to native code for iOS. See https://github.com/samskivert/ikvm-monotouch
So for iOS, you won't be able to bind the code to any form of native version, and what you have access to via the toolchain method depends very much on what Monotouch has catered for iOS (quite a lot I imagine), and also what IKVM-Monotouch has supported (I imagine the bare minimum to get PlayN working).
I'm not familiar enough with the Flash pipeline to give you an appraisal, although I think that it's quite flexible.
The above answer is written assuming your app is actually a game. If it is not and you intend to use the standard widget libraries for various platforms on mass, it should be possible. Choosing a good MVP framework would be good here, and depending on the assumptions it makes on different host environments will determine how easy the whole thing will be.
I'd recommend reading and comparing https://developers.google.com/web-toolkit/articles/mvp-architecture and perhaps look at questions like What is your favorite GWT MVP Framework?
...although a lot of these frameworks might be GWT specific and not really have catered to being reused on other platforms.
I'm about to build my first serious Lisp-based project: a web application that will need to scale to tens of thousands of users (not concurrently - probably hundreds, at most, concurrently).
The stack I'm intending to use looks like:
Weblocks web framework with a BerkeleyDB back-end
Elephant object database
Steel Bank Common Lisp (SBCL)
Ubuntu Server (10.04 LTS)
I have two areas of concern re. this stack:
Is Elephant dead? The latest release is getting on for three years old ... which could just mean that it's stable I guess :-)
As a relative newcomer to Lisp (but with significant RoR & ASP.NET experience) are any of those technologies likely to melt my head?
Feedback on my choices, & suggestions of alternatives, would be appreciated.
Elephant is effectively unmaintained. It does not work on current SBCL and the patch to fix the issue has not been applied. It's possible that someone else might pick up the development but it's not clear in the short term if that will happen. Some people use Rucksack as an object store, and bknr-datastore is also interesting.
Ubuntu is fine, but don't use Ubuntu Lisp packages; it's better to get SBCL from www.sbcl.org and libraries via Quicklisp. Because of that, almost any Linux will work equally well. I use Debian for my Lisp-powered website.
Weblocks is a continuations-based web framework - it is a very old approach, it should not be used for developing modern web-applications.
If you don't mind using PostgreSQL for persistence, you should check out Postmodern.
I have tried Weblocks, and i have made a simple web app also. But when i want to write a more complicated app, i found Weblocks is too limited. It lead user to write more widgets, but i suppose widgets cannot solve all web UI problem. I even read 80% source codes of Weblocks. But .... finally i decided to change another Web framework. What i really need, i suppose, is a url routing library like Ruby on Rails, Restas is fine. I tried it, and i wrote a blog library which support themes like WordPress using Restas. Restas is easier than Weblocks, but more powerful in my opinion.