Yes, it's entirely my fault that the account has lapsed: I took a bit of a sabbatical for full-time grad school, and it was a very busy few years.
But how crazy is it that an email marketing company thinks it's a good idea not to inform users before an account is deleted? At the very least, you'd think they'd use it as a scare tactic to drive paying customers back to the product: "If you don't send a campaign in the next X days, we'll delete your account!"
RAM and HDDs in MacBook Pro machines are user-replaceable parts. No warranty is voided provided you install the proper stuff, and don't break your system in the process. I believe the manuals include detailed instructions for the replacements.
The RAM is _very_easily_ upgraded in an iMac. Apple's even designed a nifty door to make this process incredibly easy.
The only point of annoyance here is the HDD in an iMac. The design simply doesn't allow for the HDD to be accessed, and hence it's not user-installable. Personally, I'd never buy an iMac, and I very seldom recommend them.
I've always wanted to try Numpy for this purpose, but I get exposed to so much MATLAB code in research papers for DSP that it hardly seems worthwhile.
Furthermore, I've built an entire Objective-C math framework (https://bitbucket.org/liscio/smugmath) that operates very similarly to MATLAB (i.e. vector-oriented) and allows me to easily translate DSP algorithms found in research papers over to shipping products (http://capoapp.com, http://fuzzmeasure.com).
I do all my DSP algorithm research in Octave, because the price of MATLAB is just too high. I think I'm looking at somewhere on the order of $4k for a single license to obtain the signal processing stuff that I need in addition to the core license.
Would I prefer to have more graphing options, and some assurance that researchers' MATLAB code will work out of the box? Of course!
That said, Octave gets me really close for a fraction of the price. Also, I can peek inside the Octave source and get an idea of how the underlying routines work.
I've got a fairly large install base, and I'd like to keep them happy if at all possible. In the future, when I have to get them to buy a v2 release on the App Store, then ideally I've made a good impression on my customers and they'll happily buy a license.
It's also not that big a deal to do. As long as the developer tools continue to let me target 10.5 from 10.6, I'll be OK.
I think there's not much benefit of staying on Leopard if you run an Intel Mac these days. The upgrade cost is pretty cheap, and the benefits do developers are quite heavenly.
I've been keeping Leopard support in TapeDeck because it's been pretty easy to do so, but with the work I'm doing on 1.4 right now, I've been tempted to hit that kill switch...(But I won't.)
If they email you the .app, it will be locked down to the purchaser's machine.
In terms of Snow Leopard-only, that's not necessarily true. However, it will be Intel-only.
The version of TapeDeck I submitted to the App Store had to be stripped of the ppc binary in order to pass validation. However, the version on http://tapedeckapp.com (the demo) is ppc/intel and 10.5-friendly.
I've yet to have one of the "bad" problems with PayPal, but I'm always trying to stay a step ahead of them when I can.
For instance, if you're expecting a higher-than-normal sales volume (e.g. a launch day, version upgrade, promotion), it doesn't hurt to give their Merchant Services department a phone call (the number I was given was 866-837-1851).
Be sure you ask for Merchant Services if you're not connected to them by default—it's a whole other support organization from what I could gather on my last phone call with them a month or so ago.
They may be taken aback by the reason for your call, but you can go over your phone numbers and addresses with them to make sure they can get a hold of you in the event that a fraud trigger is hit. If they can't speak with you, they have no other choice but to shut you down until you call them.
You can also get them to put a note on your account about the expected volume increase, so that when the activity does go into review, it may not be such a harsh reaction (e.g. freezing withdrawals temporarily rather than totally shutting down incoming funds.)
For the price of their service, the wide range of things you can do with their APIs, and the support I've received thus far, there's not a whole lot left to complain about IMO. Maybe my tune will change if I experience some of the "trouble" you hear about online, but I think that the proactive approach I describe above may help prevent that from ever happening.
Poor battery life? My Magic Mouse would last 3 weeks of constant use with NiMH batteries on average.
However, this was only the case after I applied the software update for my aluminum bluetooth keyboard. The first few weeks with the mouse would get me only a few days worth of use, at best.
Maybe there's another bluetooth device nearby that's causing your Magic Mouse to work too hard, and suck up too much juice?
(Note: I don't use my Magic Mouse anymore because I've since fallen in love with the Magic Trackpad, which has survived even the most precise work with Photoshop for mocking up pixel-accurate UIs.)
Are all the features accessible in non-contract plans?
I've got a few contract-only perks here in Canada on Rogers, such as the 6GB data plan add-on for $30/mo, and an "Employee Purchase Program" discounted voice service at $17/mo.
I don't think you can get non-contract data plans for under $30, and that only buys you 250MB/month, and voice plans start at around $25-30/month.
I may be able to set up a similarly-priced plan up here, but I would lose out on many of the important features (tethering, visual voice mail, larger data caps, free evening/weekend calling, etc.)
It's hard for any company to try and work against the carrier-subsidized pricing of handsets. As long as carriers are supplying the access, this will continue to be the case.
To pay $500 for a phone, versus the $100 subsidized price, is a silly move—especially if you're planning to upgrade every 2-3 years.
I say this because the service from the carriers still costs the same regardless of how you obtained the handset, and in some cases you may be paying even _more_ for service if you don't have a contract.
(Of course, I'm speaking with the US/Canadian carriers in mind. I know things are better outside of North America.)
I think that the kind of folks who are _capable_ of building significant iOS based apps simply choose not to, instead of simply producing fart apps.
I avoided the platform for as long as I could. During that time: the tools improved, hardware and APIs have improved greatly, provisioning hardware got a lot easier, and the review process shortened significantly.
So now, I'm dipping my toes in and embarking on a fairly significant app. However, because I'm a long-time Mac developer, much of my existing code and experience moves over without much fuss—perhaps the developers of "signifiant" apps just have a different kind of "fart app"?
Rob's situation is fairly unique, and unfortunate. The whole ordeal is a load of BS, and I hope things change for the better for him. Briefs is a great idea, and it was easily the coolest iOS product demo at C4[3].
I can't speak for mmastrac, but in general Rogers devices roam onto AT&T as their first choice. I've noticed similar lameness in AT&T's network while traveling...
It's probably the algorithm in question that's to blame, in conjunction with the slow OpenCL implementation for the 8800GT, as you found.
On my machine (I'm the article's author), even Apple's GPU-tuned version of Galaxies runs much faster on the Mac Pro's CPUs than the GPU. So, something's up. I think only the GTX285 for the Mac Pro beats out the CPUs on that test, but I could be wrong...
The 1-2 seconds of overhead could also be contributed to by the compilation of the OpenCL program for the GPU, as I do a compile of the .cl kernel on each run of the program.
Furthermore, I wasn't very scientific about the GPU case, because I wasn't planning to ship a GPU-tuned algorithm. To actually pull this off for a consumer app is easier said than done.
For instance, I'd prefer not to ship the .cl kernel in the application, and would rather provide binary-compiled kernels. Doing this for >1 flavor of GPU is nontrivial, from what I gather, as I'd have to actually own the GPUs in question to get compiles for the different targets (I could only cover the GeForce 9400M, and 8800GT from my own collection of hardware).
That said, I still want to stay open to the idea in the future as I play around with the algorithm, and understand it further.
Thanks for the nudge, though. I really should dig deeper.
From the brief description on the site, it sounds possible.
Kernel support is not mandatory, as it only provides optimizations. So you're good there.
You will have to supply a build of the GCC compiler that supports blocks, and make it play nicely with Xcode (provided you're talking about end-user apps to take advantage of libdispatch). This shouldn't be too bad, but requires more Xcode-fu than the majority of Mac devs have.
The thing is, you should still use NSOperation for most multithreaded coding tasks in Snow Leopard, as it is now implemented using GCD underneath. You should only really monkey around with libdispatch calls directly if you're seeing performance problems with NSOperation (verified using profiling, of course).
I think the real benefit of this OSS project is going to be porting libdispatch to entirely different platforms (Linux, BSD, Windows, ...), and building NSOperation-like constructs in other languages/APIs to be used on many platforms (including the Mac, in the end).
To me, I'd question the 'full suite' of Office that was supposedly included. Even when building through Dell, and packing in the OEM version, I'm pretty sure that alone adds $3-400 to the price.
That said, Office doesn't ship with Macs. I'm pretty sure that Macs don't even ship with the 30- or 60-day evaluation version these days.
I couldn't agree with you more. So many well-known sites are publishing terrible native apps for the iPhone which could have been much more effectively implemented by some CSS/js tweaks.
For instance, the PayPal app is utterly terrible, and gives only a fraction of the functionality you get from PayPal's full site. A few weeks, at most, could turn the PayPal site into an incredible custom iPhone web app.
And to add insult to injury, they don't even take advantage of the benefits that a native app gives you on the iPhone. For instance, they don't use the keychain to securely store login credentials so you don't have to re-login each time you launch the application (if the user requests it).
If I was worried about harsh comments, I wouldn't have started a thread, on the internet, looking for feedback. Anyway...
You bring up some interesting features—a few of which I have planned for future releases. I can't do it all in a 1.0 release, though. Someone with a "strong professional background" should be well aware that getting to a 1.0 is the toughest part of the battle.
I obviously plan to add far more functionality going forward, and you can rest assured that I have some amazing stuff up my sleeves.
Whether my customers perceive the application as a "Hello World" audio program (which I strongly disagree with, by the way) is a whole other story.
I don't think they care what's under the hood as long as it meets their needs, and does it better than anything else, and with ease. Many of the customers I've shown Capo to have never even known that time-pitch correction was possible, for instance. I can't fathom a user looking at my software and claiming, "Hey, I can code that in a weekend."
However, looking at any of the other solutions, I'm sure users would be intimidated. I want to bring this mature technology to a user base that isn't really interested in opening up a myriad of plugins and digging through complex UI.
No, these users want to be playing a song in iTunes, realize they should try and learn the song, and drag the song onto the Capo dock icon and start learning right away. That "simple" feature alone cost me about a month of off-and-on experimentation and hacking.
And, I was nice enough to share the solution to that problem on my blog for all to see, so that folks like you can make your "Hello World" solutions that much more quickly.
However, once you get to Capo's 1.0 state, I can assure you that you'll be far behind, eating my dust...
But how crazy is it that an email marketing company thinks it's a good idea not to inform users before an account is deleted? At the very least, you'd think they'd use it as a scare tactic to drive paying customers back to the product: "If you don't send a campaign in the next X days, we'll delete your account!"