Agreed - Plenty of hitters have experience with it as well, since it's been around the minors for even longer than this season.
I saw it in practice a few times this year during spring training games, and it was _fast_. Add to that the fact that only pitchers, catchers, and hitters can request one (no managers holding the game up while the replay room checks on it), and it really won't slow the game down at all.
The fun part will be seeing how teams learn to game the system. The batter can call it, but I think it would be hard to stifle any kind of communication from the dugout.
/something higher tech than banging a garbage can obviously.
It will be fun to see if teams prefer batters or catchers use the system. Or if they will coach either side to use it situationally. I think, so far, catchers have better challenge success rates?
I agree entirely. It's especially frustrating since the DeviceActivity framework comes close, but doesn't provide enough detail for users to allow apps to track this info.
The best approach we've found to tracking specific app use time is to have our app publish App Intents, and then tell users to trigger those intents with shortcuts. It's fairly effective, but very clunky to set up and has to be done app by app..
Hey - if you're interested in prototyping with real data, we've built a platform for stuff like this -- Fulcra Context (https://www.fulcradynamics.com/). We have an iOS app that collects Apple Health data, and you can then share it with a coach/trainer/doctor/etc.
As the article notes, DEC's OSes largely dodged the bullet by having good workarounds and in-kernel implementations for the missing instructions.
Open-source VAX OSes weren't so lucky. BSD's libm used EMOD pretty heavily (for modf() and the like), and this caused problems in unexpected places if you happened to be running on a newer machine that didn't have these instructions (stuff like: awk would crash!). So the OSes had to follow suit as well, at least for the instructions that libraries / compilers would emit (which fortunately excluded most uses of the G and H floating types). The documentation available at the time was okay but.. imprecise.
Sheesh, kids these days. 'Responsible disclosure' used to be about not screwing over the numerous people running a piece of software. Then it became about helping websites implementing software to regress us back to centralized computing. And now it's apparently about helping preserve clunky business models by helpfully suggesting exploiting weaknesses in TLS. What's up next, volunteer implementations of using nmap for client OS fingerprinting so they're even better able to extra money from more-capable device owners? Or helping to conceal the latest government trojan? Sigh.
It's a bunch of little niggling aspects that add up into just feeling the whole thing is yet another gimmicky disposable income scoop for out of touch spendthrifts.
1. Fifteen different prices depending on what alleged type of device you're using, and gasp whether you have more than one.
2. Internet access is only required for most tasks due to people's laziness of using webapps.
3. Alternatively, "yay, I can refresh reddit on a plane"
4. Partial Internet access given before payment, to make it as disruption-free as possible, even though it will necessarily end up admitting things like the original article.
5. These whole "enter your credit card" wifi networks in general. Network access is infrastructure. Yeah, it takes a bit of work to backhaul a plane. But it also took quite a bit of work to build the plane. Just make the infrastructure universal so we can rely on it instead of clouding the thing with massive transaction overhead.
6. Why give the spineless airlines any more money than you have to? This attitude is subject to change when they start sticking up for their customers by giving the TSA the boot.
But honestly I'm doubt I'm going to win any points for these views on HN. I should probably just turn my commenting threshold back down.
> 1. Fifteen different prices depending on what alleged type of device you're using, and gasp whether you have more than one.
The device type is a good indicator of bandwidth usage. It's sensible to bill using this model for now. They could use metered bandwith, but something tells me you'd complain about that too.
> 2. Internet access is only required for most tasks due to people's laziness of using webapps.
What does this have to do with anything? People use the internet for all sorts of stupid stuff. I happen to use it mainly for vpn and ssh, but why does it matter?
> 3. Alternatively, "yay, I can refresh reddit on a plane"
So? Again, who cares?
> 4. Partial Internet access given before payment, to make it as disruption-free as possible, even though it will necessarily end up admitting things like the original article.
Partial access is given due to exclusivity deals and that sort of thing. Would you prefer the alternative of just not giving you anything? Who the hell complains about free? Seriously.
> 5. These whole "enter your credit card" wifi networks in general. Network access is infrastructure. Yeah, it takes a bit of work to backhaul a plane. But it also took quite a bit of work to build the plane. Just make the infrastructure universal so we can rely on it instead of clouding the thing with massive transaction overhead.
You do realize that Boeing, Detla, and GoGo are different companies right? Also, it takes a lot more than a "little bit of work to backaul." It took GoGo many many years working with the FAA, ISPs, and others to only just recently get this setup and approved. Look at what's happening with the dreamliner if you want an example of what can go wrong if you do this incorrectly. Finally, most of the planes in a typical airline's fleet are decades old. You can't just bake this cost into the price of the plane (as if that makes sense anyways. not all 747s are passenger planes). With your proposal, we'd maybe get wifi in 2030 (assuming this proposal would be possible at all, which I doubt it would).
> 6. Why give the spineless airlines any more money than you have to? This attitude is subject to change when they start sticking up for their customers by giving the TSA the boot.
OK, seriously, W.T.F. are you talking about? The TSA is employed by the airport, not the airline.
Re: 6 - I should also say that to "give the TSA the boot", it is the US government who should stick up for its customers and end this security theater.
"This is Visa's OCE, or Operations Center East, the biggest, newest, and most advanced of its U.S. data centers. It is a data-security heaven--and Visa's acknowledgment that hackers are increasingly savvy, that data is an ever-desirable black-market commodity, and that the best way to keep Visa (and its 150 million daily transactions) safe is to ensconce its network inside a heavily fortified castle that instantly responds to threats.
The OCE's 130 workers have two jobs: Keep hackers out and keep the network up, no matter what. That's why rule No. 1 for visitors is: Never reveal its location. "On the eastern seaboard" is as specific as Visa will allow."
This is a very hacker-unfriendly device. I wouldn't buy one.
The SDK's compilation tool doesn't invoke a compiler; it uploads your code to a service running off of http://174.129.29.50:8080.
The Arduino is fantastic because the bootloader is open-source, the hardware is open-source, and it's easy to find out full information about the hardware and pull the MCU datasheets yourself.
How can you call it "hacker unfriendly"? The thing is designed to be hacked, that's the whole point of it.
The Arduino and this are two totally different classes of devices.
For staters, this appears to be very much about the hardware. I wouldn't expect it to be open source, just like the iPhone or Motorola Droid you can develop your own apps for doesn't have open source hardware. You don't actually have to be granted access to 100% of the codebase and hardware layout for a product just to develop a neat application around something.
I saw this and immediately thought of 5 or 6 cool uses for it so I bought one. Sure, if I was going to build some kind of a product around this, or develop an app that was going to be my retirement income, I'd want a little more information about the company and their licensing models. But for a $150 hackable gadget, this thing is one of the coolest toys I've seen in a while.
I think it's a pretty good idea, but the ideal solution would be both a CAAS and the opened sourced toolchain that worked on at least one open source platform. Doing that is probably easier than releasing something cross platform like arduino, and for most people is going to be easiest to use.
Hi Guys, Eric from inPulse here. We're trying to make it as easy as possible for people to develop for inPulse. That's why we've built a cloudcompile service. No messing with DLLs, drivers and other annoying parts of embedded coding.
I think we've succeeded! In our beta testing, users were able to go from downloading the SDK zip to loading their first app on inPulse within 5-8 minutes. I think that's pretty impressive for a startup hardware biz.
If you'd like to setup the arm-gcc toolchain and compile your own apps, absolutely no problem! We'll have instructions online shortly. If you need them faster, just email devsupport@getinpulse.com
It's certainly easy to use, as long as the server remains up. But do I still have full control over the code that I upload to you, or does it count as "user-generated content" in http://www.getinpulse.com/terms/? What privacy guarantees do you make regarding the code that I upload? (Hopefully very little; it is transmitted in the clear, after all..)
We live in a world where device vendors (even small ones) routinely use technical means to thwart hackers and other tinkerers. Often, this is done under the guise of usability or security (sometimes with some justification, even). Plenty of people don't mind trading away some control for stability or ease-of-use.
This is a forum for hackers, and you just called your device "hackable". I'm saying that it's not, currently; it's a black box with an SDK that does cloud compilation. You don't document that fact anywhere or provide an ready alternative, and there's no information about what's underneath your API, either OS or hardware.
This is extremely important - the claim to user-generated content is either boilerplate and wasn't intended to apply to actual software, or it is specifically intended to apply to the uploaded code due to the cloud-compile service.
The question has been asked a couple times here - is there an answer?
You've made some very good points. We'll strive to improve over time, and you comments/questions here will help guide us. Any and all comments are welcomed to devsupport@getinPulse.com
I encourage you to try out the hardware, throw it on your wrist and wait for the amazed looks from passersby. It's quite awesome having a net-connected terminal (I pair my inPulse with my Blackberry) right on your wrist.
For technical sites like Hacker News (and to some extent, reddit), it seems like marketing speech is actually more likely to turn off potential buyers than attract them. See the IE9 AMA debacle on reddit, for example. We're hackers here, and blunt truth tends to be valued more than softer wording.
I read it as more of a politic answer, there's been a lot of inpulse bashing it seems over what appears to be something that they are doing to try and help, not thwart hackers.
Encouraging us to get one for the Blackberry is all well and good, except its pre-order only, not shipping yet.
I wish the blackberry 'edition' was $99 (for black.) Then I'd get one. It seems disproportionate to the blackberry cost itself at $199
I've never heard of a cloud compile service, but I think in this case, it's a good idea. Especially since not many people have experience with cross-compiling.
One of the things that make Arduino so popular is the ease of use in getting code a) to compile and b) get uploaded to the device. If this works via a service, then so be it.
But, I would like to see instructions for setting up a local amr-gcc toolchain, just to be complete.
"ARM Cortex-M3 Core running at 96MHz, 512KB FLASH, 64KB RAM and lots of interfaces including Ethernet, USB Device and Host, CAN, SPI, I2C and other I/O."
<200mA, $59
I want one, but I already have an arduino thats been laying around unused and unloved for some time :(
Appcelerator Titanium, a relatively prominent open source alternative to Adobe AIR, does cross-platform app compilation on a 'cloud compilation' service:
We're trying to make it as easy as Arduino to develop an app for your watch! To dodge the arm-gcc toolchain issue, we've built a cloudcompile system which allows all platforms Mac/Ubuntu/Windows to have an equally easy time compiling. Simply code your app in C, then run our python script to compile your code and load it onto your watch, wirelessly!
Also, your terms of service (http://www.getinpulse.com/terms/) states that you claim rights over information I upload to sites run by Allerta. That must include code I upload to be compiled, correct?
From the terms: "hereby grant to Allerta a perpetual, irrevocable, non-exclusive, worldwide, royalty-free license, with the right to sublicense, to reproduce, distribute, transmit, publicly perform, publicly display, digitally perform, modify, create derivative works of, and otherwise use and commercially exploit any text, photographs or other data and information you submit to the Website (collectively, User Generated Content) in any media now existing or hereafter developed, including without limitation on websites, in audio format, and in any print media format."
As I mentioned, we're releasing the entire SDK with instructions on how to compile using the full arm-gcc, right on your local machine. We just started off with this cloudcompile service to make it super easy for everyone to get Hello, Watch! (http://getinPulse.com/apps/hello_watch) running.
We are developers ourselves and committed to providing the best experience possible. We'll work fast to get the full toolchain out there.
Your python script uploads my code to your server and sends me back a binary in return. What happens when that server goes down?
Getting people up and writing code on devices quickly is awesome; but sending code (unencrypted, even) off is pretty shady, particularly since you're not disclosing it to anyone.
Arduino manages to have a cute little barebones IDE based around an actual compiler; and they provide full hardware docs, links to datasheets, the works. You're doing exactly the opposite of that. Even Apple will let me compile code for my own iOS devices -- after I've paid the $99/year fee or jailbroken, of course...
Right, I just remembered about the MagicJack. From what I understand it seems to be a service, rather than a product, isn't it? And it also won't work without an Internet connection.
That's an interesting read by the way. Pretty damn good for a "weekend project" :)
it's both. it's a hardware device with an rj-11 (normal modular phone) jack and a basic line simulator that lets you make calls using SIP. there's also a (pretty cheap) service that is billed fairly infrequently. alternatively, you can use asterisk with the magicjack device; quick googling around shows that people have figured out what's necessary to get the two working together.
the downside is that it's not wireless, so you need a separate device speaking USB either way..
I saw it in practice a few times this year during spring training games, and it was _fast_. Add to that the fact that only pitchers, catchers, and hitters can request one (no managers holding the game up while the replay room checks on it), and it really won't slow the game down at all.