Nathan Borror wrote a great post about reverse-engineering the Sonos API in order to create a custom iOS application, OS X client and turning off speakers when he leaves home.
Nathan also documented the design- and code-wise progress on GitHub.
I enjoy posts like these where somebody is scratching an itch by reverse-engineering an already existing product. Wish more of the posts on HN were like this one.
SummaList promises to âsummarize all the best tech & startup newsletters.â sending you one weekly e-mail with summaries of the best newsletters.
I donât want to receive any more emails, and generally just like to have all my feeds/newsletters combined in my RSS reader1 - so I crawled the RSS feeds from all the sites currently on SummaList.
For a similar service that offers summary of interesting content do check out Blinkist.
Grab the OPML file with RSS feeds of all2 the newsletters from SummaList below.
Just switched to the new beta of Reeder 2 for Mac, and syncing with Feedbin ↩
Sites without RSS feed: Corbett Barr ↩
We all know that testing is good, and most of us hopefully already write tests for our front-end JavaScript code â but is it needed for our Sass code as well?
We need to think about long-term maintenance as our Sass projects and libraries gets more and more powerful. Just look at some of the things Sass can do today, things nobody wouldâve imagined just a few years ago:
The term Sass unit testing is not referring to visual regression testing of the visual end-result, but instead logical unit tests focused on the core functions of a library. The term is also not referring to linting of sassor scss, if thatâs what youâre looking for scss-lint may be for you.
The logical testing of functions that an entire project relies on, just makes plain sense â additionally creating tests upfront prevent regressions later. Testing your individual functions will force you to break up your code into small modular functions, and maybe even adopting techniques like object oriented css.
If youâre using continuous integration in your deployment process you are probably already running existing tests before deploying, the first step to making sure your Sass doesnât break on deployment is making sure that it can compile with errors.
In case youâre already using Grunt for your local development workflow it would make sense to just make Grunt run your test and build tasks. If youâre using Travis itâs just a few simple steps to make your Grunt tasks run on every new build.
No matter what build system you are using, the key is that the build will fail if compilation of Sass/Compass fails - the last thing we want is for broken output css to make it into production.
A BDD-style framework that doesnât rely on any frameworks.
Bootcamp is developed by James Kyle who have done some crazy things with Sass, checkout his GitHub. The syntax for Bootcamp is clean and obvious, especially if youâve worked with BDD frameworks in other languages before. You begin a new test suite by calling the mixin describe with the title for the spec suite and then the @content block inside:
@include describe("A suite") {
@include it("contains spec with an expectation") {
@include should(expect(true), to(be(true)));
}
}Specs are called by the mixin it which just like describe takes the name/title and a @content block. The spec contains at least one expectation which evaluates to either true or false, a spec with at least one false assertion is a failing spec.
The syntax for defining suites and specs are important, but the matchers that are available in assertions are just as important. Bootcamp comes with a bunch of rich matchers already included. An extensive list and demo of each matcher is right here.
Itâs possible to disable suites and specs by changing the mixins to xdescribe and xit, just like Jasmine.
You can install Bootcamp from either npm or Bower:
$ npm install bootcamp --save-dev
$ bower install bootcamp --save-devAfter installing Bootcamp youâll probably want to add it to your Sass :load_paths, instructions for Grunt and Compass:
npm './node_modules/bootcamp/dist'
bower './bower_components/bootcamp/dist'tests.scss
@import "bootcamp"; // or "[node_modules|bower_components]/bootcamp/dist/bootcamp" if you didn't set load_paths
@include runner-start;
@import "specs/example";
@include runner-end;To run Bootcamp and get the results of the test suite simply compile the tests.scss file. If youâre using Grunt in your workflow please see a full working example in the official documentation.
The wiki for Bootcamp includes a full working example.
A TDD-style framework inspired by QUnit.
True is developed by the talented Eric M Suzanne who also gave a great talk at SassConf â13.
In True you define a suite with the mixin test-module with the title of the suite/module and again utilizing the @content block:
@include test-module('Column Math') {
@include test('[function] is-symmetrical()') {
@include assert-true(true, 'Number should be symmetrical');
}
}Individual specs are defined with the mixin test which again takes a name/title. True contains 4 different assertion-types: assert-true, assert-false, assert-equal and assert-unequal.
True can be installed with RubyGems:
$ gem install trueAfter installation youâll need to add the following line to your config.rb:
require 'true'It can also be installed with Bower or by copying the Sass directory from the project.
After install creating a test suite is a simple as creating a main test file.
tests.scss
@import "functions/all"; // functions we want to test
@import "true";
@include test-module('Column Math') {
@include test('[function] is-symmetrical()') {
$s: is-symmetrical(12); // externally defined function
@include assert-true($s, 'Number should be symmetrical');
}
}A great production example of True can be seen found Susy Next.
As Chris Eppstein mentioned in his talk âIt Takes a Village to Raise a Websiteâ at SassConf â13, the community/ecosystem really needs to rally around these new unit testing frameworks.
We as a community need to figure out what it is that we want to test. What is missing in the current frameworks and maybe even in the Sass language. How are we going to do unit testing in Sass in the future.
Do we want a standard set of assertions and matchers in the Sass language, which we as a community can build different language/syntaxes on top of?
Update 1: Corrected mistakes in section about True, especially about dependencies on Compass, Ruby etc. Thanks to Eric for correcting me.
Full disclaimer: I worked for Spiir a couple of years back.
Why is it that you as a banking customer arenât the owner of the data you generate?
The reason for this post was a recent incident in my home country Denmark, a Danish startup Spiir was reported to the police by the third largest bank in Denmark, Jyske Bank who is accusing Spiir of using âhacker-methodsâ to unlawfully gain access to usersâ financial data.
Spiir enables users to get a complete overview of their economy by analyzing transactions. In the early days of Spiir, the only way of getting your transactions from your bank into Spiir was by exporting, one account at a time, into CSV files and then importing these into Spiir. It worked, but it was too much of a hassle and broke the immediate feedback-loop that was important if users were to spend time on something as unsexy as bank data.
Spiir started a partnership with another Danish bank, LĂ„n & Spar Bank, that allowed for automatic transfer of data from the bank to Spiir â if the customer wanted so. Most of the other banks were not as keen on this kind of partnership, even though their users were publicly asking for the integration.
Spiir then started looking at alternative solutions, so that their users could do what they wanted with their own bank data. It was clear that the banks were using relatively simple APIs for their own clients (mobile applications, etc.), which could potentially allow users to programmatically access their own data more easily than the manual CSV export.
After substantial investments into the legal aspects of this new kind of integration, Spiir launched an automatic synchronization of the bank data to Spiir. The legal aspects of this synchronization are clear because Spiir is only accessing the bankâs API on instructions from the user and not in a way that the user himself couldnât access it. Furthermore, Spiir is only accessing the userâs data for the use of that specific user. The legal justification from Spiir can be found right here.
It is this particular integration that Jyske Bank find illegal. We are talking about a service that simply accesses an API on behalf of a customer who wants to use their own data in a way that the bank doesnât approve of.
Even though Jyske Bank keeps calling Spiirâs methods for hacker-methods, it is clear to anybody who have the slightest technical knowledge that those claims are without merit. An example of the hack can be seen in this Gist by @soerenr.
This is a market ripe for a significant technological disruption, and we are already seeing players attacking this market from multiple positions.
We see it in the customer-facing sides of the market with startups such as Simple, Numbrs, Moven, Holvi, Tink, RocketBank, and so on. But I think, just as importantly, we are seeing startups focused on making the data from financial-institutions more easily accessible for developers and users:
It is time for the banking world to wake up and realize that the world around them have changed completely.
We should demand that our providers, no matter what type (bank, email, social network, etc.), set our data free. After all, we are the ones who generated and accumulated the data in the first place - is it not only fair that we can do whatever we want with it?
Every time I see company fighting this hard to keep user data to themselves, I canât help but think that either they are relying on a dying business-model or they just simply donât get what is happening around them. I donât see how companies that actively fight against their customersâ wishes can survive in this day and age.
I, of course, know that change takes time, especially when it comes to big slow-moving companies such as banks, but that shouldnât stop us from pursuing more open data from the services we use everyday.