 |
|||||||||
|
|||||||||
|
|
We've all heard the saying, The grass is always greener on the other side. Basically it refers to the entirely delusional situation where, once in a rut, you fool yourself into thinking that any situation other than the one you're currently in is better than your current situation.
Windows developers often suffer from "green grass syndrome" and go explore different pastures - Mac development and Linux development. Client-side developers explore server-side code, web programmers tinker with desktop application development. A lot of people dislike the "greener pastures" effect, but I think, when used properly, it is one of the single best forces in the world of programming today.
If people didn't seek greener pastures, people wouldn't learn to expand their current horizons, they wouldn't think out of the box, and they would never experiment with new and interesting technologies. Without the greener pasture effect, I'm afraid the world of developers would lack any real form of innovation.
The real issue, and the crux of this post, is this: How do you tell the difference? How do you know what what you are feeling is objective, or what you are feeling is the semi-euphoric glaze of the Greener Pasture effect? I'm not sure anyone knows... I sure don't.
What I do is I take a step back from the situation and try and look at it objectively. It's difficult, and often forces me to break my current workflow or even withdraw from the greener pasture and go back to the "old pasture" to re-evaluate things in a new perspective.
One such perspective that I evaluated was the IDE. I have been poking around with Cocoa and Objective-C at home in my spare time, partly because of the Greener Pasture effect, partly because it's something I don't currently know (and I am driven beyond the point of obsessive-compulsive with regard to learning). When I started working with Xcode and IB, I felt like a fish out of water. The experience was very strange, and I didn't know how to do anything. Now that I've been using it for a while, I find it very intuitive, very easy, and very natural. As I've mentioned before, I actually feel relaxed while using Xcode and IB (especially the ones that come with Leopard).
In the interest of being as fair and as objective as possible, I pulled back away from Xcode and IB and went back to spending my spare time writing .NET code. I wanted to see if my love for the Xcode and IB interfaces was influenced by the Greener Pasture effect, or if the interfaces really were that much better. After spending a lot of time with a really critical eye on the VS 2005 interface and on the Xcode interface, I've come to some conclusions.
In short, when I first started tinkering with Cocoa I found Xcode and IB to be intimidating and confusing. Now that I know a little bit more about Cocoa itself and the underlying frameworks, I am more aware of why IB and Xcode do what they do, and I am also more familiar with it and more comfortable with it.
When using Visual Studio 2005 I find myself missing the feeling I get when working with Xcode/IB. I have never before encountered a situation where I missed the visceral experience of a tool more than its raw feature set. I have taken a step back, gone back and forth between both IDEs and tried to compare on their own merits (since, because Cocoa is fundamentally different than .NET, a direct comparison won't mean much), and, to me, Xcode and Interface Builder seem to be more conducive to producing high-quality applications. I'm not saying you can't produce a high-quality app in VS 2005, I'm just saying that it feels like Xcode/IB steer you down the right path and occasionally VS 2005 actually prevents you from going down the path you want to go down.
I'd love to hear your thoughts, especially if you have used both IDEs yourself. What was your feeling switching between the two?
I'm not sure exactly what you mean by "group a bunch of related projects",
but a single xcode project can have multiple targets to build different
things. So, you can build both a client and its server in the same xcode
project by just switching the active target.
Are Xcode targets not not sufficient for your multi-part project needs?
I've recently discovered that there's a lot more power and flexibility
there than I had imagined.
I'll have to check into Xcode targets. I may be stuck in "Visual Studio"
mode where, when I think of multiple targets, I think of nothing but
"Release" and "Debug". Building a client and server with 2 differentargets
might be something I can explore next time I get a few spare minutes.
each target in xcode is independent of the others and has a full set of
compiler/linker setttings of its own as well as its own set of dependency
lists.
Also don't miss out on the power that .xcconfig files can give you... they
can make large project sets easy to manage and keep in sync
For me, double-clicking on a component in VS that has a text feature (like
a button) and, instead of allowing me to edit that text inline, creates an
action method for me - drives me nuts!
I love being able to double-click a button and edit it's text. That's an
incredibly quick and easy way to get a GUI up and running.
I find multiple targets are good if the products share a lot of code and
you are basically working on these multiple targets at the same time. It is
also possible to create target dependancies between entirely separate
projects. Simply add another .xcodeproj to the files of your project and
then edit your target dependancies, the targets in this other project will
show up and you can build them as a dependancy in your current project.
Combine inter-project dependancies with multiple targets and there are a
ton of choices.
One example of a multi-project Xcode project is Jamie Zawinski's
screensavers (see my URL for the link.)
it seems like your major beef with vs2005 is that you can't seperate the
partial classes for your view. the problem with that is you are a bit
misguided with regards to the MVC pattern. the "code-behind" partial class
IS the view. controllers should be implemented as seperate classes so that
they are testable independent of the view. if you cant test them alone,
doing any MVC-like pattern is a waste of time. read more about it here: ht
tp://codebetter.com/blogs/raymond.lewallen/archive/2007/02/20/Controller-_2
1003D00_-code_2D00_behind.aspx
I'm not misguided in my interpretation of MVC. I realize that the
code-behind class is the view. In knowing that, I put my .xaml AND my
.xaml.cs file in my "Views" folder. The issue is that VS 2005 just makes it
so bloody easy to blur the lines of concern. It takes a LOT of discipline
to keep the view code in the view, especially when, realistically, you need
something like Model-View-Presenter or you need an intermediate
"ViewModel".
step into xcode ( http://elfurl.com/m4vyh )is a good book for explaining
multiple targets in one project and manage the dependencies. it focuses
more on the in's and out's of xcode (hence the title) rather than cocoa, so
things like this and build configurations and using SCM are talked about as
well.
"When using Visual Studio 2005 I find myself missing the feeling I get when
working with Xcode/IB. I have never before encountered a situation where I
missed the visceral experience of a tool more than its raw feature set."
