Unlike PhantomJS, this is not a headless browser (though can be!), its a browser that can be designed in HTML/CSS/JS. This is to say, the navigation buttons are controlled by you, your own download manager, etc. Time and imagination are your limits.
I develop on Windows for Windows and use these tools. Here is my reasoning.
It's easy to see that Unix shell tools are much superior to the Windows cmd. There is PowerShell which gives you more flexibility, but in my experience I have found PowerShell to be slow. It also has a totally different set of syntactic rules which aren't worth my time to learn.
Given that, I would rather install Cygwin or MinGW. Spinning up a VM is much more heavy-weight that just directly using Cygwin.
> There is PowerShell which gives you more flexibility, but in my experience I have found PowerShell to be slow.
Powershell can be a little slow to launch. Actual execution speed is pretty respectable. It does get faster after the first couple of times as it will ngen stuff into the GAC (this is particularly bad on new Windows installs where little .Net code has previously ran in any contexts).
>> It also has a totally different set of syntactic rules which aren't worth my time to learn.
>You're missing out. Powershell's syntax is quite intuitive after you learn the basics, you quickly start to be able to guess commands and params.
I have grown up using Unix tools and I am quite comfortable with them. If I have to learn a new shell and scripting language, there should be a demonstrable benefit for the time I spend learning it. Can you give examples where PowerShell can do something which CygWin/MinGw can't? Trying to understand why you say that I am missing out :)
> Can you give examples where PowerShell can do something which CygWin/MinGw can't?
As those contain full programming languages which can effectively do anything with enough effort I doubt I can.
I will say the DateTime, cultural conversion, and email libraries are an absolute pleasure to work with in Powershell/.Net. Sending out email is a totally trivial exercise regardless of the style (plain text, HTML, attachments, etc).
The main benefit of PowerShell over other shells is the object pipeline.
In classical shells, a pipe basically connects binary stdout -> binary stdin. A pipe between PowerShell cmdlets, on the other hand, can produce .NET objects directly without having to serialize them, so the pipe can connect .NET object producer -> .NET object consumer. If the consumer can't handle objects, the pipe degrades to binary stdout -> binary stdin.
For instance, the pipe in `ls | grep` is drastically different from `ls | fl`, because the latter is an in-process transfer of a .NET object collection, while the former transfers lines of text from one process to another, (in this case, to GNU Grep.)
Upside: the consumer doesn't have to "parse" stdin to get reasonable data on which it can operate.
Downside: if you want to write a consumer, you're stuck in .NET land. (Oh, how I wish I could write a consumer written in python that could advertise that it supports a specific object-oriented serialization on stdin! Then we could write a PowerShell stdin/stdout compatibility layer into python as a module... Alas, I'm guessing this task is reasonably hard.)
The main problem of object pipeline is that only software written .Net understands it. That means most of the utilities we are familiar with in the Linux world doesn't work with them.
And I don't want to find every .Net equivalent of the command I use in Unix systems. Perhaps all the coreutils have counterparts in Powershell, but for all the other third party ones I use, probably not.
Look pretty slick. It's interesting that it's marketed as a fitness device but is actually a smart watch. I own a Garmin Forerunner 305 which can last 6-8 hours of active use. I know that the recent Garmin devices last close to a day. The Microsoft Band doesn't tell us how well it does on battery with the GPS -- without the GPS it claims 48 hours.
If you're using gps to track running and such, you aren't running 24 hours a day, so you can save battery by turning it on and off. I think that's a great feature. But it would have been nice to say 'GPS' time, like phones describe 'talk-time'.
There are times I wish I could leave GPS tracking on all the time, with a simple way to add markers either now or later, and with the ability to share the data with any app I want. There are times I just want to hop on my bike and ride without doing some dance with a finicky GPS app that I have to remember to stop at the end (and hope it doesn't crash during my ride).
For what it's worth, any Android phone with Google Now already can track you (albeit without super high resolution) 24/7. It's actually kind of cool; it looks at where you are and how fast you're going to infer walking vs biking vs driving.
>If you're using gps to track running and such, you aren't running 24 hours a day
I run and cycle. I and many people I know do cycle ~ 12 hours in a day, while training. Right now the choice among road bikers I know, is the Garmin 810 which lasts that long with continuous use.
Technical users can and will block access to portions of the API during authenticatcaion, but what about people like my parents? They might very well login, giving full permissions to the app, seeing that it's a trusted google URL while not knowing what they have done.
To me it looks like when they published their app from the US, they got all valid reasons for a rejection. The fact that Toshl's app was present for an year with all these faults is not a good argument for being automatically accepted.
