Best way to begin?

Discussion in 'Mac Programming' started by iStudent, Dec 31, 2006.

  1. iStudent macrumors newbie

    Sep 19, 2006
    University Heights, OH / Canonsburg, PA
    Happy Holidays MR Programmers,

    One of the things I want to accomplish in the New Year 2007 is to write my own ice hockey management software. I want to bring fantasy hockey the Mac community and to the hockey community in general, since we've been striving for a solid game for awhile. Although I have been programming solidly now for at least 4 semesters, I've never really had to go start-to-finish on one whole application by myself; rather just tweaks and small-scale homework assignments. Basically, my question is how to kick off something like this. Mainly, what is the most efficient and best way to store data? How can I put stats, players, coaches, teams, box score, etc. information to use? Databases? Massive arrays/lists? Has anyone done a similar project that can help me get off the ground?

    Thanks in advance,
  2. slooksterPSV macrumors 68040


    Apr 17, 2004
    Personally I say CoreData TO THE RESCUE!

    CoreData would probably be the easiest way to do this. You just setup the information in the CoreData modeler, and set it all up. I'm going to package my assignment data manager application so you can see how I did that one and kind of replicate it, meanwhile I suggest you look up a CoreData tutorial. It's so easy! Oops can't use my DreamWeb browser, be back on Firefox to help with this.
  3. mbabauer macrumors regular

    Feb 14, 2006
    Well, this is my thoughts:

    First off, this sounds like more of a web site than a dedicated MacOSX app. By doing this as a web site vs. an application you open yourself up to not just Mac users, but anyone with a browser. Thats my $0.02 worth, though.

    If you are stuck on an app, I would also agree CoreData is the way to go. It handles all the object creation/serialization for you...real easy.

    As for how to get started, there is the quick-and-dirty way and the best-practices way.

    The quick-and-dirty way would be to crack open XCode (or whatever IDE you use) and start hacking code out. You do this until you get a completed program that *mostly* works, then you fix bugs. This has the benefit of quicker time-to-market for smaller endevors, but the downside of being very disorganized.

    The best-practices way would be to step back, take a look a the project as a whole, and plan stuff out. As youself:
    • Is this going to be Open Source?
    • Where am I going to put the source code?
    • How is it going to be delivered? Are people expected to compile it themselves, or are you providing a binary distribution?
    • Web App?
    • Am I going to support this if there are bugs? How?
    • Who is my ultimate target audience?
    Doing this steps you through the process, from planning, to coding, to deployment/packageing. The upside is that you do things right, to anticipate the work and plan accordingly for it, and you are very organized. The downside, well, its that you can turn a 2 day coding project into a 3 month documentation project. Plus, no one like paperwork.

    So, I say just go for it. Start by making a list of the things you really want to accomplish, like features etc. Us this project as a means to learn something new, like a new language or some new library or something. Get any books you need to help you along the way, and ask lots of questions on the forums.

    Good luck!
  4. zimv20 macrumors 601


    Jul 18, 2002
    i'll add that, imo, the missing bit isn't technical, it's managerial. this is a good kind of project for someone who wants to develop software for a living in a team environment. the keys are planning and organization, and you'll get experience in the lifecycle of development: requirements, design, code, test, integration, deployment, maintenance.

    there are lots of models that describe how to develop software. for example, i've never been an advocate of the waterfall method, or at least how i've seen it implemented, i'm much more a fan of a prototying / iterative process.

    you'll also get to play software architect, as you figure out how to persist the data (yes -- some kind of database, probably relational), define processes and their interfaces, specify development and deployment platforms, etc...

    much of the architecture and design can be done independently of the final technologies, though i'd recommend technologies be kept in mind. iow, don't pick a technology first, then decide to base how your system will work, or what you're allowed to do, based on that technology's limitations.

    this is a big subject. i urge you to not think of this as a homework assignment scaled up, but rather a whole new approach to developing a system.

Share This Page