Kristel Viidik is the co-founder and CEO of Testlio where she handles everything from answering every support e-mail to acquiring new customers and making them fall in love with Testlio.
Testlio is a full-service software testing solution. We remove the need to build an entire QA department in-house by partnering with our customers and assisting in managing their testing process using our community of top testers. ... Our vision is to completely change how QA is done.
Many companies are afraid of outsourcing because the quality tends to suffer. However, compared to hiring your own testers in-house, outsourcing is much more affordable. At the affordable cost of outsourced prices, Testlio gives companies a dedicated team of software testers with years of experience collectively.
I'm a professional tester. I was looking to do some testing on the side because it's something I genuinely enjoy. I joined several of our competitors as a tester and found that their model rewarded the quantity of bugs caught rather than the quality of the findings.
Serious flaws quickly stood out. I didn’t feel like I was a part of the testing team for each app I worked on. Testers weren’t communicating or collaborating with one another. It was like we were testing in a vacuum.
This is important because creating a high-quality app is a team effort. Testers, developers, designers, and product all need to work together. Quality is everyone’s responsibility. Anyone can find the low hanging fruit, but if you really want to make an excellent app, everyone involved in the product has to work together.
To date, we are rapidly expanding our customer base and we pride ourselves on having a community of the top testers in the world.
Firebase has been a significant part of our success in bringing together our awesome community of testers.
Communication between testers and customers is incredibly important on our platform. To facilitate this, we’ve created a real-time chat system using Firebase. If it weren’t for Firebase, creating this chat system would have been prohibitively difficult.
Testers and customers communicate on projects. It’s important that there aren’t any bug report redundancies on these project reports. We use Firebase to do real-time checks while testers are submitting a bug to prevent these redundancies from being submitted. This way, no one’s reports will be overwritten or duplicated.
Testers applying to Testlio have to go through a rigorous verification process. A part of this process is a mobile testing game we’ve created. This game serves as a quiz to assess the applicant’s testing skill. We use Firebase to keep track of each applicant’s progress in the game and entire application process.
Testlio is currently built with php, HTML5, node.js, socket.io and redis with AWS for hosting. However we are in the process of completely revamping our stack. In the very near future we will be using Koa, io.js, and React.
One of the features our customers love is App Store Reports. A lot of companies are interested in what their end users are telling them. App Store Reports aggregates the data from the app store and sorts them by feature and/or product areas so customers can see exactly what’s doing well and what needs improvement.
Testlio is also very popular for beta testing. Our platform makes it easy to add beta testers and customers receive all their reports in one place. Testlio has made this entire process super simple.
An exciting new feature is automation support: you write your test scripts on our platform and we take care of execution. All the results are available in Testlio and you’re immediately notified of any failures. We’re currently testing this feature with a few of our early customers and it will be available to everyone very soon.
We're constantly improving our product. Not only are we completely changing our technology stack, but we're also revamping our design, onboarding, and general UX of the product. We value user feedback more than anything, so if you have any suggestions please tweet them to us @testlio or e-mail us at hi@testlio.com
The Ember CLI is a command line interface that provides a default project structure for your EmberJS application and makes it easy to develop according to Ember's conventions. It is quickly becoming the default way to build Ember apps. After hearing about all of the new features for Ember CLI at EmberConf earlier this month, I was excited to try it out with the latest version of EmberFire, Firebase's adapter for Ember Data.
If you're new to Ember or the Ember CLI, this video will walk you through Ember's core concepts and the basics of developing with the CLI. In 9 minutes you'll learn how to build a chat application that uses EmberFire to persist data:
To learn more about using Firebase with Ember you can check out our EmberFire quickstart or step by step guide. I'd love to hear what you think of the screencast. Leave your feedback in the comments or find me on Twitter @SRobTweets.
Hi, I'm Tim! I’m the newest member of the Firebase UX Team. I've been an avid Ember user for two years, and I've spent my first few weeks at Firebase adding new features to EmberFire. On the UX team, I’ll be working on building out features in the App Dashboard.
Last week Sara and I attended EmberConf 2015 in Portland, Oregon. We had a great time meeting a ton of awesome people in the Ember community and hearing about what's coming up for Ember in 2015. After getting feedback from many of you, today we're releasing some new features in EmberFire, our official bindings for EmberJS.
As Ember development moves towards Ember CLI, the latest release includes much better CLI support - you can easily install EmberFire as a CLI addon and the FirebaseAdapter will automatically be initialized in your application adapter. This release also adds support for querying your Firebase data. Details on both new features are below. Also, a special thanks to Matt Sumner for his contributions to this release on GitHub.
FirebaseAdapter
EmberFire now supports ES6 modules and is packaged as an Ember CLI addon by default. You can get started with EmberFire in your CLI app in two steps:
From your CLI app’s directory, run the command:
$ ember install emberfire
This will add Firebase as a dependency in your bower.json file and generate app/adapters/application.js for you.
bower.json
app/adapters/application.js
The ApplicationAdapter generated by running the install command references the config.firebase variable in your config/environment.js file. Next, update your Firebase URL to that file:
ApplicationAdapter
config.firebase
config/environment.js
$ firebase: 'https://YOUR-FIREBASE-NAME.firebaseio.com/'
Now your Firebase data will automatically be synced with the Ember Data store.
The latest release also loosens our Ember Data requirement. You can use EmberFire with Ember Data beta-11 through beta-14.x.
beta-11
beta-14.x
You can run our example blog app by running ember serve from the root of the emberfire/ directory.
ember serve
emberfire/
For those of you who aren’t using Ember CLI yet, don't worry - you can still use EmberFire! Just include EmberFire and it’s dependencies in your HTML from our CDN. Check out the instructions in our guide for details.
When we released additional querying methods, many of you asked for direct support for this in EmberFire. This 1.4.1 release includes findQuery support! You can now use Ember’s findQuery method to order your Firebase data by a specified child or by key. Using this sample Firebase of dinosaur facts as an example, the following query will return the two tallest dinosaurs:
findQuery
//app/routes/dinosaurs.js export default Ember.Route.extend({ model: function() { return this.store.find('dinosaur', { orderBy: 'height', limitToLast: 2 }); } });
Check out the EmberFire documentation on findQuery for more details.
Finally, we’d like to hear what you think as we continue to improve EmberFire. We encourage you to submit a PR on GitHub, and share your feature requests with us @Firebase on Twitter or in the comments below. We’re excited to see what you build with Firebase and Ember!
Important note: Firebase private backups have changed since this blog post. Please see the updated details here.
.json
security_rules.txt
Today we’re excited to introduce version 1.0 of AngularFire. This new release focuses on enhancing two characteristics of AngularFire: stability and simplicity.
With a 1.0 release we will guarantee backwards-compatibility with all future 1.x.x releases. We would like to thank those who built amazing apps during the beta. Without your support and feedback AngularFire wouldn't be what it is today.
The goal of AngularFire is to remove the complexity of synchronizing collections. The 1.0 release removes the overlap between the Firebase SDK and the AngularFire library. AngularFire is now focused on on what it’s good at: synchronized bindings. We've removed the $firebase service in favor of two new services: $firebaseArray and $firebaseObject. Authentication through the $firebaseAuth service is already stable and remains unchanged.
$firebase
$firebaseArray
$firebaseObject
$firebaseAuth
The $firebase service added an unnecessary step to the synchronization process. The 1.0 release cuts right to the chase. If you need a synchronized array, inject the $firebaseArray service and pass it a reference:
app.controller("Ctrl", function($scope, $firebaseArray) { var ref = new Firebase("https://<YOUR-FIREBASE-APP>.firebaseio.com"); $scope.items = $firebaseArray(ref); });
It's a similar process to use $firebaseObject to create a synchronized object:
app.controller("Ctrl", function($scope, $firebaseObject) { var ref = new Firebase("https://<YOUR-FIREBASE-APP>.firebaseio.com"); $scope.obj = $firebaseObject(ref); });
These new services are functionally equivalent to the $asArray() and $asObject() methods present in AngularFire 0.9. For example, the 0.9 $firebase(ref).$asArray() method returns the same array as the 1.0 $firebaseArray(ref).
$asArray()
$asObject()
$firebase(ref).$asArray()
$firebaseArray(ref)
The 0.8 release introduced the $extendFactory() method on arrays and objects. This powerful method provided transformations on AngularFire to fit your own model's behavior. In the 1.0 release we've renamed it to $extend().
$extendFactory()
$extend()
script app.factory("ArrayWithSum", function($firebaseArray) { return $firebaseArray.$extend({ sum: function() { var total = 0; angular.forEach(this.$list, function(rec) { total += rec.x; }); return total; } }); });
You may notice that the new operator is now optional for $firebaseArray and $firebaseObject. However, when using $extend(), we must always use the new operator.
new
app.controller("ArrayCtrl", function($scope, ArrayWithSum) { var ref = new Firebase("https://<YOUR-FIREBASE-APP>.firebaseio.com"); $scope.data = new ArrayWithSum(ref); });
We take pride in our documentation at Firebase. Now that AngularFire has hit 1.0, it deserves a guide with an expanded structure that mirrors our other SDKs. We’ve paved the way for continued updates to add relevant samples and sections.
Visit the new docs for a step-by-step development guide on mastering AngularFire.
For those of you who love require(), AngularFire 1.0 is the release for you. Angular 1.4 and AngularFire 1.0 now support CommonJS:
require()
var angular = require("angular"); var angularfire = require("../angularfire");
We are providing a migration guide to upgrade from previous versions. The migration guide can be found here.
We want to know what you think of the new features. Drop a comment below or send us any feedback on our Angular Google Group.
For more information check out the new in-depth guide. Or for a crash course, visit the AngularFire quickstart or try the five minute tutorial.
