I've recently setup an instance of TestSwarm that interfaces with BrowserStack by using the testswarm-browserstack nodejs module (https://github.com/clarkbox/testswarm-browserstack). I was referred to use the nodejs module from a link on BrowserStack site that walked through connecting TestSwarm to BrowserStack. Everything seems to be working as expected except that non-Windows OS's don't kick off in my automated process.
I have a bunch of OS X browsers configured on TestSwarm that seem to be configured correctly, they just never get launched during the automated runs. I'm able to join the swarm manually with BrowserStack, where I manually pull up an OS X browser and browse to the join url on my TestSwarm instance and it will properly pick up the browser and start running tests against it. The testswarm-browserstack nodejs module just seems like its ignoring the OS X browsers when it requests browsers from BrowserStack.
According the the documentation the testswarm-browserstack nodejs module should be able to handle OS X browser request as it uses BrowserStack API version 2.0 (https://github.com/clarkbox/testswarm-browserstack/pull/33)
Here is a small sample of how I'm specifying OS X browser in my TestSwarm configuration file:
"OSX-10-6-FF-22-0": {
"browserFamily": "Firefox",
"browserMajor": "22",
"browserMinor": "0",
"osFamily": "Mac OS X",
"osMajor":"10",
"osMinor":"6"
},
"OSX-10-6-Safari-4": {
"browserFamily": "Safari",
"browserMajor": "4",
"browserMinor": "0",
"osFamily": "Mac OS X",
"osMajor":"10",
"osMinor":"6"
},
Any incite would be appreciated, thanks!
I checked the link and can see the configuration is bit different. It specifies to mention browser, version and os. ex:
'Safari|5|0': {
browser: 'safari',
version: '5.0',
os: 'mac'
}
So does BrowserStack expects. Check the api docs at https://github.com/browserstack/api. Do comment back if you have your own config translator.
Related
here's the problem.
I've wrote an app with tlg module. LINK GITHUB
I've developed using Mac Os and everything worked fine but when i've tried to move all the app to a new Centos 8 VM, recompiling TDlib and launcing the app, here's the response after the app crash.
[ 0][t 4][1588032092.051109791][Status.h:191][!Td]
Unexpexted Status [Error : 0 : Too much data to fetch at 8] in file
/td/td/telegram/Global.cpp at line 77
This is weird, i've never seen an error like this. Here's the Global.cpp
You probably used your app with a newer TDLib version and then came back to the old version, so the old td can't work with upgraded DB. So just stick with the new version.
I am deploying a meteor application to a digital ocean droplet with meteor upload. Everything goes well, the application gets deployed, database works, seeding of data works etc. But there is one problem i can't seem to be able to solve.
I use the meteor-uploads package (https://github.com/tomitrescak/meteor-uploads) for file uploads. Locally everything goes well, the file gets uploaded, finished callback gets called etc. But once I have deployed the application to the server it keeps giving me on of these errors, :
POST http://*ip*/upload net::ERR_CONNECTION_REFUSED
POST http://*ip*/upload net::ERR_EMPTY_RESPONSE
POST http://*ip*/upload net::ERR_CONNECTION_RESET
Any ideas are welcome, I have searched all over for a solution but none seems to fit my problem. I also installed to a fresh droplet but that didn't help. In none of my browsers (Mac Chrome, safari & firefox) does it work, on my phone (Android 5.0) I get the same errors. I am using the newest Meteor version 1.1.0.1
On local host you don't need to set the environmental variables, but the host services provides you should.
Check this tutorial to see how to put the environment variables.
Because the file-upload needs a startup-server-configuration, like this.
//file:/server/init.js
Meteor.startup(function () {
UploadServer.init({
tmpDir: process.env.PWD + '/.uploads/tmp',
uploadDir: process.env.PWD + '/.uploads/',
checkCreateDirectories: true //create the directories for you
})
});
But im not sure if putting this on a startup will work on digital ocean, like i say you you enter it, run printing and check if the /.uploads/ exists
I am working on an application for Audio/Video calls using easyrtc.
I have added turn server details in server.js file to configure the turn servers I want to use.
var myIceServers = [
{url: "stun:stun.anyfirewall.com:3478"},
{url: "turn:turn.anyfirewall.com:443", "username":"xxxxx", "credential":"xxxxx"},
{url: "turn:turn.anyfirewall.com:443?transport=tcp", "username":"xxxxx", "credential":"xxxxx"}
];
then set options for appIceServers using below line of code.
easyrtc.setOption("appIceServers", myIceServers);
and configured the listener as well.
easyrtc.on("getIceConfig", function(connectionObj, callback){
callback(null, myIceServers);
}
After this when I am running easyrtc simple audio-video demo, from local machine, in chrome using two tabs it works fine.
Now I have two questions:
How do I make sure that easyrtc is using custom supplied TURN server configuration ?
And from where I need to test the links for my application, which will make sure that easyrtc is using custom supplied TURN url for tcp ? (i.e. firewall check).
You can turn the "log level" to "3" in server.js to see more detail logs, and use chrome://werbrtc-internals to see the chrome webrtc logs . I just set up a TURN server yesterday and in my way , I modified the easyrtc_default_options to using my own TURN,I think your configuration will work if you test with two client in different network, the Turn server will give you a feedback.
"from local machine, in chrome using two tabs it works fine." this is not using you TURN server.
I wan't to protect the code of my node-webkit desktop application packaged in an exe file.
The problem is not on the file directly but with the dedicated port for remote debugging.
Perhaps I haven't understood something but, on Windows, if I execute a "netstat -a -o" command, I see an open port associated to the application and if I open this port on my browser, I have a page with "Inspectable WebContents" and a link to the webkit application.
With this debug window, it's possible to access to all the sources of the app and I don't know how to disable this feature.
For now, I think there is no actual way to disable remote debugging in nw.js.
Even so, according to the wiki, remote debugging seems to only be executed through the command line switches. Therefore you can block the chromium command line switches (or only --remote-debugging-port) to prevent arbitrary remote debugging by user until nw.js supports disabling functionality of remote debugging.
For instance:
const gui = require('nw.gui');
const app = gui.App;
for (let element of app.fullArgv) {
// app.argv has only user's switches except for the chromium args
if (app.argv.indexOf(element) < 0) {
app.quit(1); // invalid args!
}
}
However, I am not quite sure the above code could protect your application code, because the nw.js is using Chromium internally. So that, the application code would be extracted in temporary folder on initialization. Whereas above solution isn't really protect your nw.js application. See more details: https://github.com/nwjs/nw.js/issues/269
Note: node-webkit has changed name to nw.js
I understand it's a backend server, but since people are building cross system client apps with it, I thought it was worth asking.
Is there a simple way of getting information about display count and their resolutions from nodejs? I mean the computer on which node runs, not client Web browsers.
I'll accept a Mac solution if cross system is impossible.
This is totally platform dependent. On OS X you can utilize Quartz Display Services API for that. If you're interested, I've start a package for that: https://github.com/vkurchatkin/quartz-display-services.
It's pretty raw now and the only thing it can do is returning array of displays with pixel dimensions:
var services = require('./index.js');
services.displays().forEach(function (display) {
console.log(display);
});
yields:
{ width: 1280, height: 800 }
on my Mac Pro. Obviously need to test it with multi-display setup)