I'm starting a new project based on some concepts I learned in the flashcard program.
That program is still in beta testing. The basic feature set is ready, but I'm trying to decide if I should delay the 1.0 release to move everything into a database (rather than files).
Anyway, this one will be a memorization tool for Bible verses. I'm terrible at memorizing Scripture, and I really want to improve. Therefore, I'm working on a new utility which will help with my ability to remember.
Instead of randomization and probabilistic weighting for short-term learning (like the previous flashcard system), this one will feature a long-term memorization technique, much closer to the original Leitner algorithm. A GUI (web-based Flex, or desktop AIR, or desktop QT) will be used to select and display verses in a list, associated with a user. The verses being displayed will be weighted according to the user's ability to remember and repeat them. As users are better able to remember, they'll see them less often every day. I have some investigation to do regarding how to do the time calculations (e.g. I guessed a verse right, when should I be asked again), but that's another post altogether.
Anyway, it will be interesting to see how it goes.
Sunday, March 15, 2009
Sunday, March 8, 2009
Flex and RIA development
I had a project at work to complete. Our automated testing infrastructure has aged beyond the point of usability, and no money has existed for upgrading to a more recent version, or investing in a different system for automated and manual test deployment, tracking, and maintaining.
One of my coworkers began (several years ago) piecing together a web-based automation utility which would allow us to quickly configure and execute test servers with automated tests. The solution was, conceptually, a combination of Javascript, CSS, and Ajax, in which users could add machines to a table, drag&drop test configurations to each machine, edit the test configurations (e.g. modify the command-line parameters passed to each test), and execute the overall config by sending it to the test automation system as a single CSV string.
His work lasted about 3 months, and resulted in the drag&drop interface.
Shortly after this, another coworker extended upon this work by adding the test config storage and retrieval via Ajax. Users could [in theory] add tests to each machine, edit their respective parameters, and execute said tests. They could also quickly create test configurations which would map directly to their respective automated tests in the version control repository.
The result was pretty good, but fell short in several ways: Ajax calls only worked 70% of the time, resulting in failures to execute tests, save configurations, and retrieve various pieces of information. Each test config was stored as a Javascript file on the web server, which required users to understand Javascript syntax if they wanted to manually add or edit existing configs. It also refused to work in IE.
His work lasted several months as well before he moved on to bigger and better things. I inherited it and took on the work to make it work more consistently with our test infrastructure. This lasted for about 3 months on the system before I decided to investigate other solutions.
Enter Flex.
The original interface put together was quite sound: dragging and dropping test configs to various machines is a great idea, though difficult to implement. I wanted to keep the use model of the system, but move away from pure Javascript.
After hearing some buzz regarding Flex around the office, I decided to take a look and see if it could offer a better solution.
Frankly, I was amazed. Within 3 weeks of starting, and without any prior exposure to Flex and ActionScript, I had completely reproduced all interface functionality, and even added several extensions. Rather than relying on Javascript for test configurations, I was able to introduce XML (a more logical choice, in my opinion) for configuration storage and retrieval. Relying on the Flash player resolved the issues between IE and Firefox (and other browsers which support the issues with storing and retrieving information from the web server.
In short, Flex is a fantastic solution for developing "Rich Internet Applications." The presence of a standardized API (*cough -- javascript!*) and a full-fledged object-oriented language quickly and easily resolved all issues I had with prior implementations.
In essence, though I'm impressed with the usability and functionality of Javascript and CSS, for web apps I'm likely going to stick with Flex and potentially Cappuccino if it's as cool as it looks.
One of my coworkers began (several years ago) piecing together a web-based automation utility which would allow us to quickly configure and execute test servers with automated tests. The solution was, conceptually, a combination of Javascript, CSS, and Ajax, in which users could add machines to a table, drag&drop test configurations to each machine, edit the test configurations (e.g. modify the command-line parameters passed to each test), and execute the overall config by sending it to the test automation system as a single CSV string.
His work lasted about 3 months, and resulted in the drag&drop interface.
Shortly after this, another coworker extended upon this work by adding the test config storage and retrieval via Ajax. Users could [in theory] add tests to each machine, edit their respective parameters, and execute said tests. They could also quickly create test configurations which would map directly to their respective automated tests in the version control repository.
The result was pretty good, but fell short in several ways: Ajax calls only worked 70% of the time, resulting in failures to execute tests, save configurations, and retrieve various pieces of information. Each test config was stored as a Javascript file on the web server, which required users to understand Javascript syntax if they wanted to manually add or edit existing configs. It also refused to work in IE.
His work lasted several months as well before he moved on to bigger and better things. I inherited it and took on the work to make it work more consistently with our test infrastructure. This lasted for about 3 months on the system before I decided to investigate other solutions.
Enter Flex.
The original interface put together was quite sound: dragging and dropping test configs to various machines is a great idea, though difficult to implement. I wanted to keep the use model of the system, but move away from pure Javascript.
After hearing some buzz regarding Flex around the office, I decided to take a look and see if it could offer a better solution.
Frankly, I was amazed. Within 3 weeks of starting, and without any prior exposure to Flex and ActionScript, I had completely reproduced all interface functionality, and even added several extensions. Rather than relying on Javascript for test configurations, I was able to introduce XML (a more logical choice, in my opinion) for configuration storage and retrieval. Relying on the Flash player resolved the issues between IE and Firefox (and other browsers which support the issues with storing and retrieving information from the web server.
In short, Flex is a fantastic solution for developing "Rich Internet Applications." The presence of a standardized API (*cough -- javascript!*) and a full-fledged object-oriented language quickly and easily resolved all issues I had with prior implementations.
In essence, though I'm impressed with the usability and functionality of Javascript and CSS, for web apps I'm likely going to stick with Flex and potentially Cappuccino if it's as cool as it looks.
Subscribe to:
Posts (Atom)