cstone

The most recent draft of the Midway Rising Specific Plan (https://www.sandiego.gov/sites/default/files/2025-09/dsd_app...) says Les Girls stays; the development doesn't go north of Kurtz St.

By my reading of the map, it means that that Midway Rising will cover the Salvation Army store and everything west of it between Sports Arena and Kurtz St (including the current parking lots).

Of course, if/when Midway Rising does happen, it'll probably spark future developments..

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.

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.

We have a REST API with python client lib (https://fulcradynamics.github.io/developer-docs/), an MCP server (https://fulcradynamics.github.io/developer-docs/mcp-server/), and did some experiments with ChatGPT actions as well (https://www.fulcradynamics.com/chatgpt).

It doesn't have the simplicity of a plain export to duckdb/sqlite, but it definitely helps solve a lot of the sharing/collaboration problems.

Cool! There are also folks on Bandcamp who have floppy releases as a thing. Here's one: https://powerlunch.bandcamp.com/merch

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.

source: I wrote the EMOD implementation for OpenBSD/vax a long time ago; POLY had already been done by NetBSD. It's still there! http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/...

don't blow up the spot

"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."

uhh, right. two articles from the 90s put it in mclean, va: http://www.recordnet.com/apps/pbcs.dll/article?AID=/19940101...

http://news.google.com/newspapers?nid=1298&dat=19931218&...

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.

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."

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...

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.

What's the actual hardware inside? Do you expose (quasi-)standard ARM JTAG?

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..

it's not asterisk, but here's an iphone app for magicjack SIP: http://blog.javachap.com/index.php/how-to-make-voip-calls-on...

You're right that it should just fail gracefully, and that people shouldn't use the data for anything long-lived. I'm not so sure the latter won't happen often enough for compatibility to become an expected feature, though.

What I'm afraid of is the future hypothetical case where the scheme changes in the future and a Django developer decides to add in backward compatibility anyway--by having the verifier check the presented text against both the old scheme and the new one.

If your main point is "don't reinvent the wheel, use an established system," though, I totally agree.

To expand on the first part: with something up front saying "this key is signed using system FOO", you'll be able to support multiple systems in the future. This means that you'll be able to handle multiple systems (and upgrades) easily.

I can tell you're pushing for terseness in the signed text (every character does count), but I'd definitely consider explicitly describing the cryptosystem and version you're using in each cookie.

Also, is there some code elsewhere ensuring that the separator character is always escaped during signing? I don't see anything explicit, but I could definitely be missing something; I haven't messed with Django internals much..

You can empirically determine exactly what's in an opaque set of anything (NSArray's various public access methods) and exactly what part of the area of a view is covered by a subview. Then you can call the public removeFromSubview method on that view, and it will remove it from its subview. Then you can attach your own. Apple doesn't say you can in the documentation, but they say that UIImagePickerController is a UINavigationController, and you can do that to any UINavigationController.

You can do this at run time for any UIView, even those which are part of so-called opaque types. Those methods are documented, and you can read about them above. I'm done trying to tell you that.

I can't imagine how frustrating your iphone app development experience must be if you rule out experimentation of all types. How did you ever get past the code-signing step?

"The UIView hierarchy itself is undocumented. The ordering of the contents is undefined, may change at any future date, and can not be relied upon."

This is exactly what I said above. If you expect a certain structure, your app will almost certainly blow up, and is defective. However, you can rely on the fact that the UIView hierarchy can always be modified, with public methods, regardless of what's inside (or not inside) it. Because that fact is documented.

You're wrong. You don't have to use a single method or class that is undocumented to add or remove stuff to the camera control's UI.

Here is a link to the documentation of the class in question: http://developer.apple.com/iphone/library/documentation/uiki...

As you can see, UIImageController is a subclass of UIViewController. UIViewControllers contain a property named "view" (http://developer.apple.com/iphone/library/documentation/uiki...), which is a reference to type UIView (http://developer.apple.com/iphone/library/documentation/uiki...). UIViews contain subviews, which are conveniently accessible through the "subviews" property. Every class in subviews must also be a UIView.

Just like in any other modal UINavigationController, to modify what's visible you use the public provided methods to traverse the hierarchy of UIViews. You don't need to know anything about the classes inside; you can remove them at will, just like you can remove any other subview from any other parent. This works in 2.0 and up.

So there's no private API here. The dude even says so in the article. Now ultimately, your application will break if you rely on UIImagePickerController's view hierarchy staying constant (doing stuff like "remove the third view from the image picker's subviews array", for instance) and aren't careful about checking results. In 3.0, the UIImagePickerController's view hierarchy looks significantly different from the way it did in 2.2.1, so a lot of people's apps blew up. (On the flip side, if you were being careful, things worked just fine.)

Forget all the blathering about who is culpable to who. This guy's app (and presumably others) were defective. But platform makers make changes that break apps all the time; why should this guy get his app banned forever?

Notable information omitted from the title: the survey was of .NET developers.