Main Area and Open Discussion > Living Room

Planning a major programming project - tips requested

<< < (4/5) > >>

Josh:
I am taking all of this in and trying to determine how I want to proceed. My biggest hurdle is all of the PLANNED functionality i want in the app. Right now, I am developing a todo list of what functions I want the app to perform, and what data is associated with each data format. As I look at it, a database might be the option for actual data storage, an INI for settings and I will expand as needed. I do not want to do XML because, as I said above, this is the only app of its type and there will be no need to export it. The information entered will be from already existing documents that most personnel in my field already keep in paper form (ALWAYS CYA, as they say).

I think that once I determine functionality, what will exist in the initial release, and how the data will be formatted, I am going to proceed. GUI is still the big thing I want to discuss as I have no idea when is the appropriate time to begin design.

tranglos:
I highly recommend mouser's Idea Explosionifier
-app103 (January 13, 2012, 11:44 AM)
--- End quote ---

LOL, this is epic. And true!

TaoPhoenix:
...this is the only app of its type and there will be no need to export it. The information entered will be from already existing documents that most personnel in my field already keep in paper form (ALWAYS CYA, as they say).

I think that once I determine functionality, what will exist in the initial release, and how the data will be formatted, I am going to proceed. GUI is still the big thing I want to discuss as I have no idea when is the appropriate time to begin design.
-Josh (January 13, 2012, 02:29 PM)
--- End quote ---

Couple of thoughts.

I do recommend you plan in an export path. I and many others have concerns about Locked Gardens, wherein everything is all hunky dory until life makes you move on, then no one after you can extricate the data from the proprietary saving format. At my company I recommended twice against these kinds of "data black holes" in favor of "closer to the metal" just keeping files and then adding intelligence on top of that.

As for GUI, I'm far from an expert, so get your salt ready, but what about just start with a bunch of menus as placeholders? For GUI's you're going to get into the whole Ribbon discussion, so have a meta-answer For-or-Against the Ribbon. (Vote here: Against Ribbon, mostly.)

Josh:
The issue with data format and export is that, again, this is related to personnel records. All of the entered data exists in paper form, or digital copy depending on where it is obtained from. No tool that I've ever seen utilizes this data other than for individual download. There are no importing tools, and as such any plans for exporting will be at the very bottom of the list in terms of functionality. Not saying I won't ever implement it, but I am saying that I have no plans for the discernable future. While I will always keep it in mind, I have no plans to add it due to the nature of the information being handled. This is not like movie databases or mp3 collection managers, there information here is personal in nature, regarding to progression within my job field, and no tools exist which would make use of the types of data I plan on storing in the app. All of the individual files (training certs, etc) will be stored as their individual raw formats (jpg, pdf, tiff, etc) and as such there will be no lock-in. All of the files will be completely transportable. With this in mind, export functionality is the very last priority on my list.

ecaradec:
I went from the plan everything route then back to no planning at all. When I'm working on personnal projects, I'm very iterative now, to the point that I usually start with everything in one CPP file, then gradually move things into headers, then split headers in H and CPP. I try to reuse functionnality available in the OS and the libraries as much as possible if they don't make things more complex. I often have a pretty clear idea of what design I expect to work, so I often test that.

I take care to separe the pieces that effectivelly do something and the part that are structure. A wrong structure can be extremely damaging to a project and from what I've experienced I'm much more sensitive to go into something overly complex by planning how your project is design before getting my hands dirty. Structure is best when there is as few as possible of it. Keeping the pieces that do the work apart make it much easier to change the structure too, so this is important (don't glue everything inside deep structure hierarchy ).

All of that is learned from experience though, I don't know how much of this is transferable to anyone. I tried to explain my may to a coworker and he went into a template berzerker rage ;). I now have years of rework to get things back in order.

My current rule is now : "Don't listen too much the tips of people". If something doesn't make sense for you don't try to use it, experiment. XML can be good and bad, and INI files, sqlite or not. All of theses choices depends on very small scale decisions. If at some point a decisions make things harder, it's most likely wrong for you.

Navigation

[0] Message Index

[#] Next page

[*] Previous page