Canary.is promote their product as an alternative to a real home security system. Nothing could be further from the reality. Here is the simple truth:
if the power goes out, you will get robbed (no battery backup, probably wouldn’t make a difference even if it did, because)
if your internet connection goes out, you will get robbed (more on this later)
if your internet upload connection experiences any slowness, you will get robbed
NONE of these things is true with a real home security system.
You must understand that this is basically just a dumb camera unit that requires an internet connection to do anything. There is no local storage or functionality in the unit itself which means if your internet connection is out or slow, the Canary is absolutely useless. As a consequence, it is constantly trying to upload video for analysis (motion detection) — it can do noting on its own. Make sure you set it to ‘privacy’ mode when you are home to cut down on it hammering your wifi.
I had one unit and it sort of worked, I added a second one and BOTH of them stopped working. The more units you add, the more of your upload bandwidth they suck up (and suck they do).
Sadly, tech support is basically useless. At some point they will have you run a test on speedtest.net and if you EVER tell them you experienced an upload speed of less than 1Mbps, then, game over, that is THE problem and apparently the end of their sorry support script. It seems their ‘engineers’ are unfamiliar with data compression, efficient data streaming and error handling algorithms, etc — if you are .01 under 1Mbps (my case), then you are screwed, they won’t support their product (or allow you to return it because it says 1Mbps on the web site). It doesn’t matter if you can facetime or run google hangouts without any glitching, ‘the problem’ is your bandwidth, not their dubious implementation.
Seriously, save your money and/or look for alternatives. This canary is dead in the coal mine.
1) create list in desktop app
2) attempt to share it with my wife; sorry, have to upgrade to paid version for this
3) finally share with wife, she attempts to edit shared list; sorry, she has to upgrade to paid version (screw that)
4) remember a few more items on the go, add to list via mobile app
5) attempt to sync from mobile; get loads of errors – sync fails
6) only way to fix sync error is to copy note contents, delete note an paste contents into a new note
7) repeat from step 2 or just give up
Google Keep experience:
1) create list on tablet using Keep app
2) share with wife; no problem – she has access to it within seconds
3) she needs to add items to the list – no problem; she adds them and they automatically sync with me
4) edit list on mobile – no problem; list automatically syncs
5) both of us run Keep app in grocery store, ticking off items from the list; no problem – list syncs automatically
6) marvel at the superior user experience from Google Keep
7) BONUS: I can set a reminder on the list that is a location; Google Now notifies me when I am near the store.
Evernote just keeps getting worse and worse. About the only thing that keeps me using it is the web clip functionality in the browser. Come on Keep, add that and I can leave Evernote behind.
This is a handy new development that allows you to run Linux (Crouton) in a window on a Chromebook. It also addresses some of the difficulties of copy and paste from ChromeOS and Crouton which is something I have been missing very much.
Obviously, you can run Crouton without this plugin by switching between full screen Crouton and full screen ChromeOS, but these just feels more seemless and integrated.
I chuckled my way through this post on ‘Why SOAP lost’ because it seems to be missing some fundamental observations.
SOAP (like Java) was designed for structured use in well designed systems. most developers shy away from anything structured. It gets in the way of just writing code (or more frequently, downloading code and pasting into the editor). Much better to use JSON and write a bunch of validation code than to use SOAP/XML and re-use existing robust, well tested parsers and validators. I know, I am making a big assumption there – that a developer would actually write validation code. The more ad hoc the development process, the more ‘agile’ it is and that is good, right? Ask your friendly neighborhood QA and operations people about the value of optimizing for slap-dash development versus designing for sustainability, consistency, uptime and performance.
XML is ‘much harder to read’ than JSON? Right. Give someone a JSON document with 2-3 levels of nesting and an array or two and see how much easier they think JSON is. XML can be verbose, but that is for the purpose of clarity. Oh, and kudos for adding the line breaks in front of the namespace declarations to make your example XML look more ‘verbose’.
I’m not sure I understand the comment about SOAP usage of HTTP POST being a hardship because it can’t be tested in a browser. Easily solved by using something like the POSTman plugin in your browser. And I suppose the author is one of the service designers who doesn’t use anything but HTTP GET and returns everything (including errors) with an HTTP status of 200. Because, you know, that is easier – especially when your production environment is a browser and not a server or something exotic like that.
The last set of bullet items in the post is missing a little something as well:
Laziness, when it is the primary decision criteria, optimizes for development and sacrifices everything else. That is like optimizing for 5% or less of the lifecycle of that code. Just dumb. Be a nice person and drink your steaming cup of STFU when your YAGNI snark causes 20 hours of production downtime a month because the code has no design rigor behind it and certainly doesn’t take supportability concerns into consideration.
I bought a yubikey neo back in October and have been using it with Google’s U2F implementation. I think that this is a smart way to go security-wise and I am glad to see that Google is making it easier to take advantage of. You can also opt for the less expensive yubikey standard if you don’t have a need for the Near Field Communications (NFC) capability on the yubikey.
I found this posting to be a bit swear-y (you’ve been warned), but otherwise on the money.
The final paragraph nails it (I have definitely seen my share of those ‘success’ messages:
Above all else, have a wonderful holiday season and give your teams a break until the code freeze is lifted in mid-January. Then you can get back to shoving Agile on people, making them work 60 hours a week again and then having your directors send “we did it the Agile way!!!!” success messages after the project you executed took production offline, took twice as long to finish and cost 3 times as much.
Happy New Year! 2014 was filled with ups and downs (as to be expected). Hopefully, 2015 will see projects successfully completed and new directions explored. Coming into the new year with a bit of flu has been kind of a drag, but things should start picking up again in a few days.