|
I agree with jschell.
Here is slightly different version of that:
Inventory: id, product_id, count, date
Product: id, name, description, price, category_id
Category: id, name, description
Characteristic: id,name, description
Category_Characteristic: category_id, characteristic_id
|
|
|
|
|
To go along with the ideas previously mentioned, I actually had a similar project a few months ago. It was suggest here on CP that I do something like this:
Inventory: id, product_id, count
Product: id, name, description
Product_Specs: id, product_id, spec_name, value_type, value
"value_type" could be "TEXT", "INT", "DOUBLE", "FLOAT", etc. And the application handles the value type as necessary. So if the value type is "FLOAT", the user must input a valid 'float' value. And so on.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
|
Ah, yes, thank you for the link. Sorry, I didn't think to find it, despite how quick and simple it would've been. 
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
please tell me how to design form on window application
please also mention an example
|
|
|
|
|
|
These seem like they have potential to provide value where I work. I'm wondering if anyone is or has used them and how it went for them?
Thanks!
|
|
|
|
|
I was curious what methodologies people think work well in environments where priorities change extremely frequently.
I'm talking the kind of environment where even the top priority gets shifted before it is delivered because someone higher up in management suddenly announced a new project or task.
I've worked with several different methodologies but most of them seem predicated on being able to agree on a to-do list of at least a couple of items and sticking with that list until it is finished.
So what's a good methodology for taking that first baby step out of chaos?
|
|
|
|
|
Personally I started studying Project Management when I got fed up of being asked to code and build the wrong thing. I doesn't mean I can stop people making those decisions to change but at least it helps me deal with them.
One of the first things I learnt to do was design by interface and decouple program elements after inheriting one mammoth all-in-one program on my first job. I then taught others in the team how to do this.
Another approach is to design the functional system first agree on that and then start building/coding it. Don't sit down and start coding, as a programmer most want to but its the wrong thing to do.
Produce a plan and make people aware of the various points times where, if they want to change, its a lot cheaper to do so before that point than after it.
|
|
|
|
|
Member 8824288 wrote:
I was curious what methodologies people think work well in environments where priorities change extremely frequently. |
"Run". Seriously, if someone asks to build a castle, next day a it becomes a boat, next day a plane, next day an iBot, and I will be dropping everything until someone makes up his mind. The needs of the customer do not change "every minute".
Member 8824288 wrote: So what's a good methodology for taking that first baby step out of chaos?
Stop promising things that aren't built yet.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
“The Only Thing That Is Constant Is Change -” By Heraclitu
I found his is so true for Software Development.
In my Software Engineering training, I took a course titled "Managing Evolving System and Software maintenance". This course demonstrates that most software are not build for change.
The best Methodology embraces the change from start and allows iterative development. Agile Software Development is an example that methodology;Rational Unified Process (RUP) is another one. Agile allows incremental delivery of Business value to the project.
Therefore, the change is good as it adds clarity to the development. For one reason, in large scale project, the requirement can only became clear in an unspecified time in develoemnt life cycle. The problem is lack of a Change Management System and iterative development process.
|
|
|
|
|
Member 8824288 wrote: So what's a good methodology for taking that first baby step out of chaos?
That won't work. If I remember correctly there is even a study that shows it won't work (ACM OR IEEE years ago.) If management, not you, does not agree to a change in how they work, not you, then it doesn't matter what methodology you use.
Other than that the methodology that I would use is documentation. When they tell you to do something insist on email. And take a copy home with you. When they tell you to stop and do something else, get an email, and take it home with you.
If someone insists on meetings then follow the meeting up with an email where you ask them to confirm what is supposed to be done.
If different people are insisting on different priorities then make it their problem not yours to sort it out. Email all of them and ask which task you should work on first. If one tries to send response only to you then resend to ask that the others agree with the responders direction.
If you feel up to it the copying the boss of all of them can lead to interesting results. Although to be fair not necessarily positive ones.
But regardless always remember to be polite. Myself I like to compose an email, then let it sit for a bit, then re-read to be sure that it does not sound accusatory. As one possible way to do this always phrase it in such a way that you are asking for assistance.
|
|
|
|
|
Thanks to all of you for the replies. They have been very interesting so far.
First off, I'm probably touched in the head but I actually like working here. These people do acknowledge they are shifting us around and what it does to schedules and deliveries. So I'm not planning to run - just looking for things to make small improvements.
I'd settle for starters to even get a to-do list together that we are all seeing and is always accessible. And maybe I've answered my own question on the first step
Also, we have extremely short project schedules most projects are done within a couple weeks, many are a couple days and the "huge" ones take 2-3 months.
I was considering SCRUM but it requires an agreed upon list that doesn't get changed until delivery. I mentioned it to my boss and he said he thought trying to do SCRUM here would be like going to Disneyland and getting driven around in a golf cart but not being able to get out and ride the rides. LOL
I have worked on projects that were very formal with documents at each step of the waterfall and mandatory code reviews of all code (which had a DOD B-1 rating) to places where the only process is the one I follow myself
While I can't change the culture here single-handedly and I believe the study you mentioned, I'm still thinking there must be something I can do to start making at least a small step towards a more structured process.
My current hat is web developer for a marketing organization - front and back end - html, css, CMS add-ons in asp.net, integration with back end CRM and web service between the CRM and another server. In the past I've done real-time concurrent, automated equipment, drivers and desktop apps and managed Quality Assurance.
I've been in this business longer than I want to admit LOL but I'm still searching for what's out there that I might not have heard of yet. This is a business full of very bright people, I keep thinking someone has come up with a way to start the change at the grass-roots level. 
|
|
|
|
|
SCRUM is part of agile process. It deals with small incremental deliveries( 1 or 2 weeks). Actually the SCRUM handles well the change. I worked in team where the SCRUM is the centerpiece. All projects were delivered on time.
|
|
|
|
|
Member 8824288 wrote: I was considering SCRUM but it requires an agreed upon list that doesn't get changed until delivery
Rather certain that as stated that is not true.
Member 8824288 wrote: I'm still thinking there must be something I can do to start making at least a small step towards a more structured process.
Stop buying into the chaos. Structure your own work within your means to accomplish it. When there are abrupt midstream shifts then re-adjust the delivery estimate for what was stopped by adding more time (to restart.) And then publish that before you start working on the next project.
Member 8824288 wrote: This is a business full of very bright people,
The fact that someone is smart doesn't of course translate into efficient, organized, cost-conscious nor even capable of looking at the big picture.
|
|
|
|
|
jschell wrote:
The fact that someone is smart doesn't of course translate into efficient,
organized, cost-conscious nor even capable of looking at the big picture.
LOL very true
I'll take another look at SCRUM perhaps I've gotten the wrong impression
Thanks!
|
|
|
|
|
That is where a Change Management System comes handy, keeping track of a change request.
This is not to say you are totally wrong. Actually, you right when comes to some aspect of team communication, emails are important.
However, in a large-scale complex software project with many full-time developers, Test team, Product Manager, Requirement Engineer, Configuration Manager, Project Manager, in short a project that requires a full blown development team you have no choice, but to put implement a good methodology like Agile, among other things. Just emails tracking won't do it.
|
|
|
|
|
konate wrote: However, in a large-scale complex software project with many full-time
developers, Test team, Product Manager, Requirement Engineer, Configuration
Manager, Project Manager, in short a project that requires a full blown
development team you have no choice, but to put implement a good methodology
like Agile, among other things. Just emails tracking won't do it.
Amen!
|
|
|
|
|
|
I was looking for tools to generate" *.hbm.xml" files from database or from domain classes, after some googling I found this great tool "NHibernate Mapping Generator" :
http://nmg.codeplex.com/[^]
Hope this help you in your project so you can quickly end the NHibernate mapping operation! 
|
|
|
|
|
psst wrong forum - this one[^] is going to appreciate the info even more!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
ok, 
|
|
|
|
|
Great tools. However, with hibernate annotations *.hbm.xml" files aren't need anymore. Check it out.
|
|
|
|
|
thnks, can u give me the link to check it?
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
