We are working here to fully integrate intern tests into our development. The first thing I am hitting setting up our intern with intern is how she should develop the tests. We are running locally on our macs with the selenium-server.jar, and when we run the functional test with runner.js in node, it flies by so fast we can't really see what is working. I really want to be able to slow it down (As I could with the selenium firefox extension) and hopefully highlight what it is selecting. The most important thing would be to just slow down the execution so we can see what is working. I am also finding debugging difficult, making it hard to know what is dying.
What is your workflow for developing functional tests with intern and is there any way to just slow the whole thing down?
node node_modules/intern/bin/intern-runner config=public/js/dojo/tt/tests/intern-config.js leaveRemoteOpen
I found the leaveRemoteOpen flag. This works!
this.remote.sleep(1000);
will do this for you.
Related
I have been trying to create a device simulator for SyncML. Input would be DevInf information, using which some test cases have to be run.
Been searching on the net for quite some time now, even tried funambol and syncevo, but could not acheive this. Funambol has no support, so dropped it. Code does not compile. Inactive.
Syncevo is quite good, command line based. But is very tightly coupled with the base and hacking the devinf is not a simple task.
Can you suggest a way of implementing this, i am out of ideas now.
Regards
PS: i also tried exploring for OMA-SCTS, but seems to be outdated. Latest version is not available.
I wanted to know if anyone has been using AirBnB Rendr and is it stable and ok to use in commercial projects or is it still changing a lot?
I'm developing a website which can run both client and server based, this mean I need to be able to render pages and widgets server and client based.
The server is running Node.js, dust.js and has custom server based code to render the pages and widgets on the server side. I need to pick how to handle it on the client side.
Naturally I want to try and not repeat code, but obviously the client is different I can:
Keep my current page based server rendering and develop custom
client side code.
Use backbone.js on client side and keep my server based code the
same.
Use AirBnB rendr that is based on Node.js and backbone to use the
same code on client and o server. AirBnB Rendr Library
I like the 3rd idea very much, but I'm looking for some input from you guys.
Has anyone used it? any experience with it in terms of stability and/or how often their api changes etc?
I've just started playing around with Rendr. If I ignore the learning curve and oboarding friction, I like it a lot and I plan to write my next large production app using Rendr.
Unfortunately, as bababa listed above, the documentation needs a lot of work. There is an explanation of how Rendr works in its README and the example app's README but beyond that you'll need to source dive in order to figure out how the gears are turning. Currently, there is no forum for questions (other than stack overflow :D) and I've had a hard time figuring out its idioms on my own.
Despite all the struggles, I finally see the light and I'm starting to understand why Rendr is so powerful.
tl;dr - If you're willing to source dive and figure out your own workflow, I would suggest using Rendr. Otherwise, I would recommend going old school by writing a traditional client app with a more mature library. (is it too early to say that? =X)
Well given AirBnb is a successful commercial enterprise, there's some validation that the library works well enough for them. This question is probably best answered by watching their github commit log for breaking changes. Given backbone is 1.0 and essentially stable at this point, rendr will probably quickly stabilize, but honestly your fear of instability is probably unjustified. I think rendr looks compelling and although my current project is using a very similar home-grown solution, I would consider using rendr in a future project or even porting our code to rendr. "Stability" per say is much less important to the web development community compared to other situations like packaged or embedded software.
I used (tried to use) and Rendr on a project and gave up. There are just to many limitations (currently) and the lack of documentation doesn't help. I ended up need to rewrite the source code to accomplish some things I would consider trivial with other frameworks, such as passing multiple collections to a view. It just wasn't possible (at the time I used it) and that was a deal breaker. Not being able to pass a collection of categories and results to a page was to much of a limitation.
I have no doubt it will eventually be ready for production use, but right now I would say unless you are an engineer at AirBnb and know how to hack the source then no, it's not ready.
If you really want to know if it will work for your needs, take a look at the issue list on github. That will give you a good idea where the projects at.
Okay, here's a complicated one I've been breaking my head over all week.
I'm creating a self service system, which allows people to identify themselves by barcode or by smartcard, and then perform an arbitrary action. I run a Tomcat application container locally on each machine to serve up the pages and connect to external resources that are required. It also allows me to serve webpages which I then can use to display content on the screen.
I chose HTML as a display technology because it gives a lot of freedom as to how things could look. The program also involves a lot of Javascript to interact with the customer and hardware (through a RESTful API). I picked Javascript because it's a natural complement to HTML and is supported by all modern browsers.
Currently this system is being tested at a number of sites, and everything seems to work okay. I'm running it in Chrome's kiosk mode. Which serves me well, but there are a number of downsides. Here is where the problems start. ;-)
First of all I am petrified that Chrome's auto-update will eventually break my Javascript code. Secondly, I run a small Chrome plugin to read smartcard numbers, and every time the workstation is shutdown incorrectly Chrome's user profile becomes corrupted and the extension needs to be set up again. I could easily fix the first issue by turning off auto-update but it complicates my installation procedure.
Actually, having to install any browser complicates my installation procedure.
I did consider using internet explorer because it's basically everywhere, but with the three dominant versions out there I'm not sure if it's a good approach. My Javascript is quite complex and making it work on older versions will be a pain. Not even mentioning having to write an ActiveX component for my smartcards.
This is why I set out to make a small browser wrapper that runs in full screen, and can read smartcard numbers. This also has downsides. I use Qt: Qt's QtWebkit weighs a hefty 10MB, and it adds another number of dependencies to my application.
It really feels like I have to pick from three options that all have downsides. It really is something I should have investigated before I wrote the entire program. I guess it is a lesson learnt well.
On to the questions:
Is there a pain free way out of this situation? (probably not)
Is there a browser I can depend on without adding tens of megabytes to my project?
Is there another alternative you could suggest?
If you do not see another way out, which option would you pick?
My main question is whether it makes sense to begin with node.js as a complete server-side newb. Is JS/node.js a good choice to start server-side web-programming from scratch?
I do lots of frontend work, namely HTML, CSS and basic JS. I even wanted to start with Rails but always had the feeling that not knowing what is going on behind the curtains makes me completely uncertain about the framework - it was just too much "convention over configuration".
My hope is to learn JS in general and dive into node.js right after that. I don't know, however, if this is a good approach for a person without any server-side experience. When looking at existing node.js topics and discussions, the used terminology seems to require lots of knowledge about how servers work in general.
Have no fear. Programming is all about practice and you will do mistake while writing code. But, that is how we all have learnt. Whether it is Ruby, Javascript (via Node.js), or any other language: certain aspects of programming are common and you will get familiar with things specific to that particular language over time. Being not able to remember a syntax or convention is OK. Just have reference material on your side. In fact it is encouraged to tinker and experience "let's see what happens ?" moments. This is how you learn, IMHO.
Node.js is indeed a great choice to start learning server side web development. No doubt about that. You don't have to learn Javascript first and then start learning node. Here you can find all the resources you may want. Also, have a look at this How do I get started with Node.js
Here is what I would recommend as your learning path. This is not even node.js 101. But, it will be a great start.
Hello World on console. Dead simple and lot of fun
Math Addition. ( Nothing to do with server development, can skip, but good if you learn it ! )
Addition of hard coded inputs.
Addition where function add(a,b) is written in another .js file. Boy, now you are creating libraries !
Math addition where input is provided using command line. TIP: Use https://github.com/substack/node-optimist
Hello World on web page.
Hello World for web but without express.js to start with. Here is the code - http://nodejs.org/
Hello World for web with http://expressjs.com/.
Adding some dynamism to the response. e.g Saying what time of day it is.
Responding based on the URL paths and query string.
Serving static files such as images and css.
After completing this many tasks you will be good enough to decide what next you want to do.
Weird question, perhaps. We have a number of simple utilities written in-house that need to be run on an automated basis. These are not build jobs. Just things like running SendOutHourlyEmailAlarms.exe, KeepFoldersInSynch.exe and such. I would normally set these things up as simple scheduled tasks/AT commands (or a Windows Service if more granular control is needed over the scheduling), but a co-worker has set up a number of these tasks as build projects on the CruiseControl.NET server. I asked him why he set these up this way and his response was that the executions (and their logs, return values, thrown exceptions) were all tracked and logged and that this information was accessible through an organized interface on the build server website. I couldn't argue with this.
But this just has a smell that I can't quite identify. Is this a proper use of CruiseControl.NET? If not, what are the dangers? Even if it may fit the bill, aren't there other products better suited for this type of thing?
We have all sorts of non-build related tasks for the exact same reason as your coworker had, I want one spot to look up any and all jobs I need run.
Some Examples of our CC.NET projects:
FTP installers to Remote QA
Creating Source Code Documentation
Create VM's with the installers
installed for QA in the morning
Archiving Installers
Pretty much anything I have to do by hand more than once, becomes a project. IMHO it is much better than a scheduled task for one other reason as well. Our config files are in source control, so we have 1 place to make adjustments. We do not have to log into multiple servers and make adjustments or wonder which server did that.
I think your coworker has made a good argument. If these tasks are related to the development process, then placing them in CruesControl.Net as a project seems acceptable. I would draw the line at utilizing a development server to run production processes though. Although it is true that "If the only tool you have is a hammer, you tend to see every problem as a nail," it doesn't mean that the hammer isn't capable of solving a lot of problems!
Just because a tool is designed to solve a particular problem does not mean that it will not have equal facility at solving similar problems outside the scope originally concieved by the tool creator. If CruiseControl.NET solves these problems well, then it is absolutely the appropriate tool to use.