Author Topic: [Community Project Idea] Document Management Framework  (Read 6539 times)

0 Members and 1 Guest are viewing this topic.

M-dub

  • Guest
Re: [Community Project Idea] Document Management Framework
« Reply #15 on: October 25, 2006, 01:49:12 PM »
MP, those are some good points, but Tim's also got a point.
If money wasn't an issue, I'd love to take the route MP is suggesting, but since money IS an issue, Tim's idea has legs.
We have a drawing management database that one of the bosses designed, but I really do NOT like it and I never have.  It's been around for about 5 years or so and they've made a few changes along the way, but it isn't very user friendly.  He knows I hate it and when I was informed that I would be taking over the CAD Dept. for a while, that I would be welcome to keep track of improvements that could be made and we'd address them all at a later date.  I wanted to make the first suggestion "Start over", but I don't think that would go over too well.  :evil:

TR

  • Guest
Re: [Community Project Idea] Document Management Framework
« Reply #16 on: October 25, 2006, 03:09:42 PM »
I can't speak for anyone else but will be working on this on my own time to learn a little bit more and hopefully develop a solid understanding of C#. As I stated before my company currently has a document management system in place that works, I just think it could be better. If something fruitful comes from this then I will certainly look at replacing our current system with it but that is not my ultimate goal.

In regard to my company claiming ownership to software I work on I don't see how that's possible. When I was hired I signed an agreement stating that any patents I developed would be transferred into their name, that is all. Considering my company has nothing to do with software development and I will be developing this on my own time I'm not really concerned.

MP

  • Seagull
  • Posts: 17488
Re: [Community Project Idea] Document Management Framework
« Reply #17 on: October 25, 2006, 04:25:05 PM »
I can't speak for anyone else but will be working on this on my own time to learn a little bit more and hopefully develop a solid understanding of C#.

It's an outstanding target to use as the basis for learning C#, as one will need to learn C#, the BCL, software patterns and design documenting techniques in order to produce an efficient design that can be effectively shared with others participating in the effort.

As I stated before my company currently has a document management system in place that works, I just think it could be better. If something fruitful comes from this then I will certainly look at replacing our current system with it but that is not my ultimate goal.

Acknowledge.

In regard to my company claiming ownership to software I work on I don't see how that's possible. When I was hired I signed an agreement stating that any patents I developed would be transferred into their name, that is all. Considering my company has nothing to do with software development and I will be developing this on my own time I'm not really concerned.

And yet you should be IMO, as it is irrelevant the company you work for is not invovled in software development per se. The software amounts to a tool that may enable the company to be more effective or efficient (read profitable) and was developed whilst in their employ. On that premise and the clause you cite, they could legally assume (or fight for) ownership because the tool's concept was born of their business requirements, the expertise and experience required to produce said tool was aquired and refined whilst you were in their employ, and the tool works with their data.

I hope you understand Tim, I only ante up this opinion because I recognize the project represents a lot of work for all involved and I care for my friends. That includes you. I'm not looking for a heated debate. I'd be more than happy to find out I'm wrong. I hope ya'll care enough just to ensure your respective butts are covered by persuing do diligence to prove me wrong. Take care.

:)

Edit: Attempted to fix grammar; still a mess but alas, I'm going to play the "I'm too tired" card.
« Last Edit: October 25, 2006, 04:54:03 PM by MP »
\|// Set goal. Experiment tirelessly until
|Oo| practice has become expertise.  Loop.
|- | LinkedIn | Dropbox

TR

  • Guest
Re: [Community Project Idea] Document Management Framework
« Reply #18 on: October 25, 2006, 05:13:11 PM »
I appreciate the concern Michael. I'm fairly sure I know what I'm getting myself into and hopefully I can handle it. I've followed my fair share of open source projects and I feel I have a good understanding of how to get things done.

Regarding the issues with my work claiming the rights. Perhaps you are correct; I'll discuss with the Company President on Monday.

mohnston

  • Bull Frog
  • Posts: 305
  • CAD Programmer
Re: [Community Project Idea] Document Management Framework
« Reply #19 on: October 25, 2006, 06:10:50 PM »
I've always liked the idea of community projects but alas they are difficult.
A project like this would take a great deal of planning. If specifications are not completely and clearly spelled out the project will fail. There should be as much time spent in planning as in coding, maybe more. And the planning part happens up front which means you don't get to code for a while.
If you really want to learn C# I would suggest small apps that are limited in scope rather than any kind of document management system.
It's amazing what you can do when you don't know what you can't do.
CAD Programming Solutions

TR

  • Guest
Re: [Community Project Idea] Document Management Framework
« Reply #20 on: October 26, 2006, 04:34:25 PM »
I was just reading this about specifications. Pretty interesting.

Thoughts?

MickD

  • Gator
  • Posts: 3314
  • (x-in)->[process]->(y-out)
Re: [Community Project Idea] Document Management Framework
« Reply #21 on: October 26, 2006, 05:53:06 PM »
I agree to a point, you still need to decide what you want to achieve in the final product, from there you can build a very broad/open spec which still gives you some definite targets to hit but doesn't paint you into a corner and doing unnecessary work.

With db systems I personally think it's good idea to do what you want to do manually, that is, using paper forms and lists (tables) and real folders etc. to log and store info, you will probably change it many times before you get a system that works and is simple for everyone to use. You can get input and help from others who don't code as well.
Once you get your system design 'on paper' it's much easier to code it up, you will have forms designed and data tables and queries etc already to go.

I don't know how you would go about this particular type of system, perhaps all involved could start logging stuff down putting what each thinks is required into lists, creating basic forms to be filed per job etc and briefly documenting the process used to accomplish all this.
If you can get the design started like this it would be a snap to code up, even if it's a manual entry db at first then slip sbv in to automate the data logging at a later date, having the structure up and running should also make this much easier.
Forth is like the Tao: it is a Way, and is realized when followed.
Its fragility is its strength; its simplicity is its direction - Michael Ham

Lao Tzu: “To attain knowledge, add things
every day; to obtain wisdom, remove things every day.”

mohnston

  • Bull Frog
  • Posts: 305
  • CAD Programmer
Re: [Community Project Idea] Document Management Framework
« Reply #22 on: October 26, 2006, 05:56:11 PM »
I was just reading this about specifications. Pretty interesting.

Thoughts?

This part of it makes sense
Quote
So what should you do in place of a spec? Go with a briefer alternative that moves you toward something real. Write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, then it's too complex. This process shouldn't take more than one day.

Then begin building the interface — the interface will be the alternative to the functional spec. Draw some quick and simple paper sketches. Then start coding it into html. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground that everyone can agree on.

Confusion disappears when everyone starts using the same screens. Build an interface everyone can start looking at, using, clicking through, and "feeling" before you start worrying about back-end code. Get yourself in front of the customer experience as much as possible.

Forget about locked-in specs. They force you to make big, key decisions too early in the process. Bypass the spec phase and you'll keep change cheap and stay flexible.
That describes what I meant by "spec".
There has to be something in between "just start and everything will work out" and "analyze it until you get sleepy and give up".
My experience has been if I don't spend some time defining exactly what I want to accomplish I end up paying big-time.
I was thinking along the lines of answering questions like:
What kind of documents will it track?
How will they be stored?
What data needs to be tracked?
Who will use the program?
How will they use it?
Will the program have absolute control of the documents?
Will this be a web-based program?

It's amazing what you can do when you don't know what you can't do.
CAD Programming Solutions

TR

  • Guest
Re: [Community Project Idea] Document Management Framework
« Reply #23 on: October 27, 2006, 09:41:33 AM »
I planned on a write-up similar to what you described. Forgive me for misunderstanding as when I hear spec I think of the wet dream of engineering specifications I peruse on a daily basis. 1000+ pages trying to define every aspect of a job, most of which won't work in reality.

I also apologize for not getting this document out earlier but I've acquired some sort of throat phlegm illness similar to the croup and have been sleeping or drinking whiskey while not at work. I promise I'll write something up this weekend and will post it Monday.

MP

  • Seagull
  • Posts: 17488
Re: [Community Project Idea] Document Management Framework
« Reply #24 on: October 27, 2006, 10:59:57 AM »
I was just reading this about specifications. Pretty interesting.

Thoughts?

While there is merit to many of the 37 signals mantras keep in mind the scale of applications they author. Relatively speaking, they author small solutions. Their most ambitious solution basecamp, a service I've personally used for over a year now, is small and simple compared to a capable document management system. Indeed, one of the major complaints folks have about the basecamp service is that their document management model is anemic. It was but a month ago that they finally added crude file versioning after being inundated with requests.

If a functional spec "looks nothing like the finished product" and "has nothing to do with reality" it, in my opinion, it reflects the authors' understanding of the application's requirements and/or ability to commit it to paper, not the uselessness of the technique.

It's an art and science choosing what techniques one should employ to help one manage software development chaos, which has some dependencies on the style(s) the programmer(s) works with effectively. Should one blanket abandon specs? In a word, and in my opinion, no. If you have no target what is everyone collectively aiming for?

Should specs be lightweight? Specs should be detailed enough to fully describe (in plain language) the requirements of the software, but no more. Some applications will be lightweight, others will be more substantial. Again, it's a matter of scale.

I think "Getting Real" is a worthwhile read, and there's merit to much of what they say, principally keeping things light weight, lean, agile, responsive etc. However, I think it's important to keep in mind much of it is not new, and appears to be abbreviated regurgitations of well established strategies and techniques (as can be found in discussions by Martin Fowler etc.) re-floated in the context of the "37 Signals" experience. Subtitle: It would be worthwhile to be conversant with all the development strategies and techniques on which the 37 signals "philosophies" are based, derived and distilled from. In my opinion.

What the hell am I doing, participating in discussions like this before my first coffee?

<blink>

As I was typing this up Tim snuck in his post. Sorry to hear you're not feeling well Tim, sure hope you feel, and get better soon.

:)
\|// Set goal. Experiment tirelessly until
|Oo| practice has become expertise.  Loop.
|- | LinkedIn | Dropbox

TR

  • Guest
Re: [Community Project Idea] Document Management Framework
« Reply #25 on: October 27, 2006, 11:53:45 AM »
I think my original intentions were not properly represented. I am not looking to create a complete document management system but instead a set of libraries to be used to create a document management system. We create the tools for storage, revision control, XREF management, etc. and allow the end user to piece together what he needs to create a solution that will fit his company. This will allow the user to get exactly what he needs and not what we feel he needs.

I think taking this approach and then provide a ridiculous amount of samples for creating systems in C#, VB.NET, IronPython, Boo, etc. would provide the end user with the best solution. All we need to do is first focus on writing the server libraries (storage, etc.) and then create a nice client library that will allow users to access their document management system from any .NET client (i.e. AutoCAD).

MP

  • Seagull
  • Posts: 17488
Re: [Community Project Idea] Document Management Framework
« Reply #26 on: October 27, 2006, 12:09:05 PM »
I'm really not trying to poo poo this idea, but without a functional and discrete implementation using the framework I think it will be very challenging to design and bring a framework to fruition that will fulfill the intent. Put another way, a better approach, in my opinion, is to design a lightweight, but fully capable document management system, trying as best one can to genericize the libraries upon which it is founded so that others may benefit from the effort. Maybe this is what you mean.

Tim, I'm not picking on you. You're floating this topic to solicit feedback. Wrong or right this is just what comes into my mind so I'm sharing it. Hope you read it in that context.

:)
\|// Set goal. Experiment tirelessly until
|Oo| practice has become expertise.  Loop.
|- | LinkedIn | Dropbox

TR

  • Guest
Re: [Community Project Idea] Document Management Framework
« Reply #27 on: October 27, 2006, 01:38:25 PM »
Michael:

I appreciate the feedback.

To fully understand what I'm trying to convey perhaps it would be best to look toward the world of web frameworks for a second. For example take a look at Ruby on Rails, Pylons or Turbogears. These are nothing more than a bunch of libraries designed to work together to create a web application. You can pick and choose the functionality you would like to use and the even bypass some components using either another library or perhaps a home-brewed one. This provides a very flexible solution for developing web based applications.

Like the aforementioned frameworks we would provide a batch script that would allow us to create a skeleton application using command line switches to define which .NET language you want to create your Document Management System in. This would allow the user to then edit whatever files they need to, compile it and have a fully customized document management system.

MP

  • Seagull
  • Posts: 17488
Re: [Community Project Idea] Document Management Framework
« Reply #28 on: October 27, 2006, 02:34:20 PM »
Conceptually it sounds great Tim and I salute your goals and intent, as well as those who will be working with you to collectively bring the vision to fruition. I still maintain that without at least one concrete application to serve as a context for the use and development of the various libraries, be it public or private, it will be impractical to develop said libraries.

To use one of your examples (as I understand it) -- Ruby on Rails was born, distilled and refined from the programming work David Hansson did on the various 37 Signals products (which illuminated the need for a standard Ruby MVC/Model2 framework and provided the initial context for testing / development) -- not the other way round.

:)
\|// Set goal. Experiment tirelessly until
|Oo| practice has become expertise.  Loop.
|- | LinkedIn | Dropbox

TR

  • Guest
Re: [Community Project Idea] Document Management Framework
« Reply #29 on: October 27, 2006, 04:08:18 PM »
I hear what you're saying and I agree to a certain extent. However I feel that functional tests and sample applications using the framework should be suffice to ensure that our libraries are functional.