Interesting library for saving forms in-progress.
Category: Javascript (Page 2 of 2)
Last year I was working with Tiest, a former colleague of mine at a bank working on a system with an internal API. It was quite an experience, though I will save that for another (set of?) blog posts for another time. The application was centrally hosted with a client API that allowed people to interact with the server side. The testers needed something to help them do more exploratory testing and my former colleague came up with a great solution to this problem that I thought would be worth recording here for posterity.
Our solution had these characteristics:
- Provided through a web browser – Installing items onto the testers machines became a bit laborious, namely because they didn’t have rights to install, change or run anything with administrator privileges. It was easier to deploy the tool centrally, and then let the testers prod from afar. This was as simple as writing a page that submitted some code to a web server, that than executed it and returned the results back to the client.
- Supported dynamic execution – We could have written a web layer on top of the client API but we didn’t really want to add another layer for maintenance. We simply used the javax.script package to turn our standard POJOs into a scriptable/dynamically invokable system.
- Built in reflection functions – Using the scripting interface meant that the server would not store any state. So the server had a number of built in functions such as a
listAll(object)that would show all available property/methods to the user - Example queries stored on a wiki – When a tester would ask for something to be checked against the test environment, I would convert it into an appropriate query they could paste into the query browser window. They could then execute it, tweaking parameters, etc and learn to compose things. They didn’t have to really understand how java (as script) worked, just build on what was there.
Although I won’t be reaching into my testing patterns toolkit for this pattern too often, I feel it worked well to enable our non-technical testers to get at something given a number of environmental constraints.
We’ve been using Jasmine BDD’s framework for unit testing our javascript layer. Its been pretty decent for our needs. The documentation is pretty good, but this cheat sheet helped us much more. Just a short blog to ensure I keep a reference to it.
A couple of weeks ago 700 geeky Swedes (and a handful of other Scandinavian people) descended on Gotheburg to attend Scandanvian Deveopers Conference. It was the first year that I went along and enjoyed the experience of this conference.
The two days had plenty of options – with eleven (yes eleven!) parallel tracks including language specific ones (java, .net), mobile, upcoming things, agile methods, web, SOA, etc. Something for everyone for the most part. This invariably brought a whole collection of interesting speakers from plenty of different walks of life. I met plenty of new people and reconnected with many others.
My key takeaways
Just like many of my colleagues, I’m interested in the “what could” be for functional programming. I have my own thoughts on its applicability, relevance and maintainability to my day to day work, however I made myself attend several sessions to see what it was. Neal Ford (great presenter as usual) did a great introductory session to the mindset behind functional programming. I’m glad to see that my studies in this at university meant a lot of it I already understood (first class functions, recursion, etc). I understood, though can’t extrapolate the strength of closures (at least the way that Neal was describing them), and the real world application of currying.
I enjoyed listening to Douglas Crockford talk about the new changes in the upcoming update to the Javascript language. I found him honestly refreshing – talking about which features to avoid (and why) and which things have been added to make users’ lives much easier and still maintain backward compatability. I can’t say that I learned a lot that I could immediately apply but had to laugh at pictures like this:
I also really enjoyed Matthew McCullough’s talk on git that was both insightful and entertaining on the internals, practicals and plenty of live demonstrations using the tool. As a fairly new user to the tool, I learned quite a bit and know more about what I don’t know and can work to fill that gap.
I have to admit the keynotes didn’t really get me thinking any differently, but I think that’s more of a function of having followed Alistair Cockburn’s thoughts for some time and having worked with and understanding change (the topic that Henrik Kniberg talked about).
Recent Comments