Lost jacket at recent London.pm meeting
I attended the recent London.pm meeting at Factset's offices and really enjoyed it. Thanks to everyone who organized it and gave talks. But I think I left a leather jacket at the venue. Has it turned up? Could someone who works at Factset have a look please? Thanks in advance, -- Ed Avis <[EMAIL PROTECTED]>
Re: Lost jacket at recent London.pm meeting
Ed Avis waniasset.com> writes: >But I think I left a leather jacket at the venue. No doubt due in some way to the magic of perl, it has turned up shortly after posting my message. Apologies for the spam, and I very much look forward to not losing something at the next London.pm event. -- Ed Avis <[EMAIL PROTECTED]>
Re: Seeking UML tips or alternatives
On 2008-10-13 08:50, "Andy Wardley" <[EMAIL PROTECTED]> wrote: > > The purpose of creating an ERM is to identify the entities (nouns) in your > system and the relationships (verbs or adjectives) between them. The entities > will (usually) end up being the tables in your database and/or the object > classes in the system. It is a relatively simple process to turn an ERM > into a data abstraction layer using your ORM of choice (e.g. DBIx::Class). > > An ERM is the most important diagram you need and *possibly* the only one. > Class diagrams are useful to show the inheritance tree of different classes > (if you have such a thing), and sequence diagrams can help if you've got some > complex interaction between different parts of the system that you want to > model. Use case diagrams might also be required to convince yourself (and > others) that you're all in agreement about what the system should do from the > end-user's perspective. But apart from that, the rest of UML just isn't worth > the effort. It's a lot of paperwork designed to increase the billable time of > highly paid analysts who can't code. All IMHO, of course. Ah, the difference between management-suggested and useful-to-programmer diagrams. Personally for me I produce 2 diagrams: a class tree and an ER diagram (though I use UML class blocks to give a field listing -- really useful for reference if you have it printed big and stuck on your wall). Then again, there's nothing more enjoyable than drawing overengineered diagrams when you could be writing perl... -J
Re: Seeking UML tips or alternatives
2008/10/13 <[EMAIL PROTECTED]>: > Go for some high level use case diagrams and possibly a deployment diagram. If you go this route http://www.amazon.co.uk/Writing-Effective-Crystal-Software-Development/dp/0201702258 is better than any of the UML use case docs I've read. However, to paraphrase I think it'll tell you that use cases are more words than pictures which may not be what you want to hear. paul
Re: Seeking UML tips or alternatives
Quoting [EMAIL PROTECTED]: I'm working on a Perl project that's got pretty large. I've been putting together a detailed project plan for the management and also some of the investors. They want it to include clear diagrams and I've been recommended UML, the problem is I haven't used UML before and it's looking pretty daunting. Go for some high level use case diagrams and possibly a deployment diagram. What do the investors want to see? My guess is something that explains in really simple terms how it will be used, how it fits together with what's there already and a glance at a deployment diagram that justifies how much kit they need to fund. You can do all this pretty easily using MS Visio and using its UML templates. The O'Reilly pocket reference is okay or you could get one of those "learn it in X hours" kind of books. You'll need something more detailed on the PM/technical side for your own use but beyond them dropping it on the desk to see how thud-worthy it is, I doubt they'd understand much of it. Regards, Peter http://perl.dragonstaff.co.uk
Re: Seeking UML tips or alternatives
[EMAIL PROTECTED] wrote: [...] a detailed project plan for the management and also some of the investors. > They want it to include clear diagrams and I've been recommended UML, Did the management/investors recommend UML? The reason I ask is that UML diagrams probably won't mean that much to your average executive. Which means they either want the diagrams as evidence that you know what you're doing and have done the proper planning (even if they're not qualified to interpret them), or what they really want is a few warm and fluffy system overview diagrams that they can put in powerpoint presentations to impress other management types. Something like this (googled at random): http://cryptodrm.engr.uconn.edu/adder/diagram.png http://www.walking-productions.com/itj/docs/System_Diagram.gif Either way, I would start by producing such a diagram showing the general architecture of the system. It's a good overview for both you and the suits. The main purpose is to show the boundaries of different parts of the system (i.e. break a big problem down into a number of smaller, but well-defined problems) and to identify what is part of the system and what isn't. You should then produce an Entity Relationship Model (ERM), even if the management don't really want or need it. Wikipedia has enough info to get you started: http://en.wikipedia.org/wiki/Entity-relationship_model This is also a good intro: http://tinyurl.com/yw6f6e The purpose of creating an ERM is to identify the entities (nouns) in your system and the relationships (verbs or adjectives) between them. The entities will (usually) end up being the tables in your database and/or the object classes in the system. It is a relatively simple process to turn an ERM into a data abstraction layer using your ORM of choice (e.g. DBIx::Class). An ERM is the most important diagram you need and *possibly* the only one. Class diagrams are useful to show the inheritance tree of different classes (if you have such a thing), and sequence diagrams can help if you've got some complex interaction between different parts of the system that you want to model. Use case diagrams might also be required to convince yourself (and others) that you're all in agreement about what the system should do from the end-user's perspective. But apart from that, the rest of UML just isn't worth the effort. It's a lot of paperwork designed to increase the billable time of highly paid analysts who can't code. All IMHO, of course. http://en.wikipedia.org/wiki/Class_diagram http://en.wikipedia.org/wiki/Sequence_diagram I'm not sure if plugging one's own business on the list is considered OK or not, but if you're looking for someone to help with this process, or want someone to look over the diagrams you produce to sanity check them, then feel free to email me off list. Cheers A