Apple Unveils Extra Leopard-isms To Developers
devilsecret writes to point out that some of the new Apple capabilities for developers on Leopard have been unveiled. The most interesting parts appear to be the opening of more of iLife to other programs, and the inclusion of Ruby on Rails.
Anyone think Apple jumped on the RoR bandwagon a little too soon? The whole "movement" has lost a lot of steam and it doesn't appear to be the silver bullet everyone originally thought it was. Also, is this just part of the developer suite, or is RoR support somehow built in to the OEM OS?
Similes are like metaphors
Here's the link to Apple's page describing the developer features: http://developer.apple.com/leopard/overview/index. html
'Every story, if continued long enough, ends in death.' --Ernest Hemingway
3 browsers and 2 OSes, no luck loading the link yet.. anyone else?
The problem is clearly that you're using the wrong browser and OS combination. Keep on trying different ones. One of them will get the link to load.
This guy's the limit!
VNUnet article
Apple Insider post
Apple's Developer Overview site
I felt a great disturbance in the Internets, as if millions of voices suddenly cried out in terror and were suddenly silenced.
BOOM!
Boom... Boom.
I use both XCode and Visual Studio. I much prefer XCode and Interface Builder. There are also a lot of other very nice tools that Apple bundles for free. They are nicer to use than what Microsoft gives you, plus there are a lot of things that you get for free on Apple that you would have to buy third party on Windows such as the coverage tool (gcov) and the profiler (Shark). So, yes, Apple's tools ARE as nice as they appear to be.
Unfortunately, today I have to use Visual Studio and I'm trying to figure out how to get my program to run in a Release build. It runs OK in Debug, but for whatever reason I'm getting an error dialog about not having a manifest file to load the C++ runtime DLL (?). I wish I could use XCode to write Windows apps. Or alternatively that our Windows users would just all buy Macs.
Avoid Missing Ball for High Score
Maybe I'm missing the point here, but why would anyone pay the asking price of just under a hundred quid for a minor revision? No, this isn't intented to be flamebait - I'm a new Mac Mini owner myself and it's getting way more use than my PC. But I can't understand how Apple can charge for what is a pretty damn small upgrade. There were some major major differences between XP and 2000, and I can understand Microsoft paying for these. I can also understand Apple charging for the jump from 9.x to 10.x. But from 10.4 to 10.5? What am I missing here?
It should be noted that one of the reasons Apple is shipping Ruby on Rails is that Rails was developed on Macs, all the major Rails developers use Macs, and the preferred editor is a Mac application called Textmate.
"Sufferin' succotash."
I'm a die-hard Mac user at home, but I write games for Windows (using MS's dev tools) for a living. As a Mac development hobbyist, I spent years using Metrowerks' CodeWarrior IDE, and -- more recently, and to a lesser extent -- Xcode.
Although I prefer the look and feel of Apple's dev tools to Microsoft's, I find that I get work done more quickly with Visual Studio than with Xcode. More accurately, I get work done more quickly with Visual Studio and the excellent third-party plugin Visual Assist, which provides a number of important code navigation shortcuts including code completion that completely eclipses VS's IntelliSense.
Visual Assist is one of those tools that's painful to be without once you start using it. It sounds like the company isn't planning on a Mac version, which is a shame... do any Mac devs out there have tips on how to make the Xcode development experience less painful -- specifically, how to deal with its poor code completion facilities and slow text editor?
I'm a Linux and Mac user at home with almost no MS software (I have played with Vista RC1 recently and have Win2k in a VM for web site testing). I'm not a fan of MS or their software but I have to use XP at work. I think it's important that I say this up front because of what is to follow.
We have VS 2005 at work and I recently got permission to install it (no one else was using it as our resident Windows dev has gone back to Delphi) to create some tools to make my life easier. I have to say I was very pleasantly surprised. I can make my tools very quickly indeed with C# and .NET and the IDE is pretty good.
The downside is that .NET can make you lazy because it does so much for you. It does 90% of what I need but the last 10% has me spending too long looking through the docs to see if there are properties, methods or events that let me do what I want easily. For example, I'm using a TabControl but I couldn't find a way to detect right-clicks on a TabPage's tab so I could pop up a context menu so I wrote some code to loop through all the TabPages, see if the right-click was on each TabPage in turn and if so pop up the context menu. I'm still learning the framework but that seems like a round about way to do things and something that should be there already.
Next to VS 2005, Xcode/Objective-C/Cocoa feels quite "old school" but I like that. It's more like the way I was taught. It can be hard work but it's worth it. I think Apple's approach may be less RAD but it maybe a more flexible approach. It's too early in my VS 2005 usage to be sure. At least Apple provide dev tools with their OS. If you want to attract the home coder you need good free dev tools so I'm glad MS offer the Express versions of VS and I plan to look at at least Visual C# Express to see how that compares to Xcode.
Andy.
On PowerPC you'd only want applications that actually need to do 64-bit math or address more than 2 or 3 GB of memory to be 64-bit, but for x86 it's a different story because the extra registers that are available in 64-bit mode may make applications that have no use for 64-bitness in itself a lot faster.
So I'm curious as to what developers will do. Hopefully, they'll evaluate the performance of their code and compile for 32 or 64 bits depending on which is faster. But of course you want your app to work on older Macs too, so you may need to include:
18 MB may not seem so bad at some point in the future. :-)
Ars Technica said Quartz 2D Extreme was there and possible to use, just not enabled because it probably hadn't been completely worked out by Apple yet.
But given fact #1, that Ars said that Q2DE is basically like running your whole desktop as an OpenGL scene, and fact #2, that Leopard will have "resolution-independent interfaces," I'm betting that Q2DE is fully running and implemented in 10.5.
It is these last two that are of real interest. Individually they are just adding more security features under the hood, which most people will never notice. In that case it is great, but nothing too new. Together, however, they could be the groundwork for just the type malware/spyware defense some security people have been hoping for for years.
Imagine a system where all unsigned code runs in a sandbox by default, without access to any files it does not create, the internet, or any important parts of the system. Realistically, people want to run software they don't trust. They will run it. Most people don't understand the idea of multiple users as a security mechanism. It does not make sense to them that you need to create a new user account to sandbox an application and it is painful from a usability standpoint.
This announcement could be the first indication of the first real, usable desktop that has the benefits of some of the most secure workstations on the planet. Who cares about RoR tools in OS X server?
This is admittedly off-topic, but...the fix for the "error dialog about not having a manifest file to load" is to generate a manifest (linker setting and also the new "manifest tool") and use the new "assembly" based deployment model. The release builds of CRT in VS 2005 have a runtime check which throws an exception if you don't have either a manifest resource (embedded) or .manifest file (detached) for your application. In other words, M$ is FORCING you to use their new deployment model now, whether you want to or not. And just for the sake of doing it - the .DLL's themselves don't care how they are deployed as they still run on pre-manifest systems.
Yay assemblies! They're like frameworks, except without versioning and without the development time support! More effort to build and you get nothing out of it.