mfp's two cents

...on Dynamics AX Development!
  • mfp's two cents

    Anyone interested in developer documentation of X++ code?

    • 8 Comments

    A new feature in Dynamics AX 2009 enables developers to write developer documentation directly in the X++ Editor while writing the production code. The feature is very similar to the XML documentation feature in C#.

    Basically any method can contain /// (triple-slash) comments followed by structured documentation in XML format. Here is an example:

    The developer is assisted by a dynamic documentation template, which is inserted through an editor script. The template automatically builds a skeleton including all the required tags for the current method. On top of this the written documentation is validated by best practice rules; which effectively prevent the documentation from growing stale. Finally a tool enables extraction of the documentation, so it can be processed outside AX, e.g. for publishing on MSDN.

    But who really cares about this? Great tools won't make my day - I want documentation!

    Dynamics AX 2009 contains about 125.000 table and class methods in the SYS layer. To give a perspective on this number, it will take you over 15 years to document them all, if you can document 5 methods an hour.

    All the methods shipping with Dynamics AX 2009 will have some documentation:

    • 10% will be available in the X++ source code, in the product documentation and on MSDN. This content has been written by developers for developers. (and reviewed by Content Publishing).
    • 20% will only be available in the product documentation and on MSDN. This is pattern matched documentation for methods such as main(), construct(), pack(), unpack() and parm(). This documentation has been written once for each pattern, and then applied to all methods matching the pattern.
    • 70% will only be available in the product documentation and on MSDN. This is automatically generated minimal documentation for methods that we haven't manually documented. It contains syntax and other high level information.

    Or in other words:

    • You will never see the dreaded boilerplate "At the time of publication..." again.
    • About 40.000 methods contain human written developer documentation.
  • mfp's two cents

    «Inside Dynamics AX 4.0» издана в России

    • 2 Comments

    Участвуя в онлайн сообществах посвященных AX, осознаешь как важно понимать русский язык: русское сообщество AX помогает друг другу и обеспечивает обмен информацией практически по любому вопросу связанному с AX, являясь отличным примером силы онлайн сообществ. Я горжусь тем что работаю над теми же продуктами что и вы!  

     

    Я только что узнал что книга «Inside Dynamics AX 4.0» была переведена на русский язык. Надеюсь что эта книга поможет вам в ваших будущих проектах!

    Удачи!


    A big thank you to Kirill Val for helping me with my first blog in Russian.

    Here is another picture of the new book.

     

     

     

     

  • mfp's two cents

    Late night discussion on software development #2: Estimation

    • 1 Comments

    “How can it be”, I wonder out loud, “that our projects always finish on time with a little less functionality than we anticipated?”

    “As far as I understand, it is no wonder that your projects finish on time, as you have a fixed delivery date. At that date you basically ship what you’ve got.” Søren answers and sips his wine.

    “Well, shipping is a big word. After the development phase we go into a stabilizing phase which can be long and demanding. We really need these fixed dates, as our customers expect us to deliver on the date we announce. ” I feel myself already in defense, and I try to steer the discussion in the direction I want it to go, “What I struggle to understand is, that even when we start out with the best intentions, we always end up cutting functionality away.”

    “Ok,” Søren replies, folds his hands, and looks at me, “this is as good a topic as any. Let me hear how you figure out how much you can do within the development phase.”

    “First of all we have a planning phase with a long list of features and functionality that we would like to implement. This list is based on customer feedback and market demands. As you might expect the list is so long, that even with all developers in the world and an undisturbed decade, we wouldn’t be able to get to the bottom of it.“ I exaggerate to drive home my point, ”The list is then prioritized, and the developers are asked to give estimates for the top items on the list.”

    “So at this point you have already trimmed the list of features?”

    “Yes, at this point we have a net list of features. The developers go away with this list, and do their magic; you know, prototyping, designs, specifications, and so on. Then they come back with estimates. With the estimates in hand we can derive a plan. Typically this includes trimming the list of features even further. We end up with what appears to be a realistic plan. We often leave a few more features in the plan than the estimates allow for, just in case a feature is finished early.”

    “Do you have reason to believe your developers over-estimate?”

    “No, on the contrary. If they were giving too long estimates the features would have been cut early, and we wouldn’t have this problem; where we cut features as we run out of time."

    “So do you believe your developers under-estimate?”

    “I have no reason to believe so. They have been doing this for so long, and are really a great team, and they have a remarkable tendency to hit the right dates. Having said this, they do miss the dates occasionally. “

    “And what happens when they slip?”

    “Well, since they set the initial date. It is their responsibility to catch up. Typically they do overtime to get back on track.”

    “And when they don’t succeed in catching up?”

    “Then we have a problem and have to cut features from the product. Which is my headache – why can’t we implement according to our plan?”

    Søren is quiet for a moment. I use the pause in the discussion to refill our glasses.

    “Let me ask you this,” Søren says, “Suppose I asked you to paint my house. You can take as long as you like, but you need to tell me up front how long it will take. If you are not finished by the time you promised me, you’ll have to pay me a compensation for each minute you are late. How would you estimate this painting project?”

    “When you put it like that, I would naturally build a lot of safety into the estimate, so I’m certain I can finish well before time. I just wish that my developers could finish on time!”

    “Do the rules your developers play by resemble this scenario?” Søren asks.

    “Thinking about it, their behavior does, but the outcome certainly doesn’t. They are not finished well before time.”

    “That is because building software is different from painting a house. You know you are done when the last board has been painted. That is not true for software. There is always something more you can do. Adding more comments, writing more tests, refactoring, just to name a few. This is the developer’s baby; they want it to be as perfect as possible before passing it on. When they finish before time, they will spend whatever time is left polishing it off.”

    “I know, I was a developer once”, I smile, “and I’m fine with that. Delivering polished features sounds good to me. The problem is we end up cutting some.”

    “Let us look at the painting project again. Regardless of how conservative your estimate is, you may get surprised: the foundation might not be in the condition you expected, you may run out of paint, the ladder might break, and the brush might be too small, and so on. Regardless of the precautions you take real life can and will play tricks on you.”

    “Yeah, we have all been visited by Murphy.”, I smile.

    “The only sane way to deal with it is to include variation in the planning of the project.”

    “Hang on a second. “, I have to digest what I just heard, “Are you saying that whenever we finish a feature early it doesn’t mean the next feature will start early – and whenever a feature is late it delays the rest of the plan?”

    Søren is silent. I shuffle my feet, feeling awkward. After what seems like a too long pause, I say, “I think you are right; even when we build in a safety buffer into all our estimates we run out of time. What else is there to do?”

    “How about delivering even more features on time?” Søren takes a pen from his inner-pocket, leans forward and grabs a napkin. This is what he draws:

    “Basically this is what you currently do. Each feature is protected from variation by the buffer your developers build in to avoid working overtime. Suppose you remove the buffer from each feature, and add a buffer in the end instead. It probably has to be somewhat larger than the buffers you use today. Something like this”, Søren continues to draw.

    “I see the point. This way each feature will commence as soon as the previous is done, and any variation might be caught up during the project, and if not we have the buffer in the end.” This feels good, perhaps too good to be true; napkin-drawings and red wine have a tendency to simplify things. After a short while I’m able to put words to what disturbs me, “this would mean our developers have to give shorter estimates. I don’t want to go onto their turf, questioning their work.”

    “Well, you don’t have to”, Søren answers, “you have to ask for estimates differently. Instead of asking ‘When can you be finished?’, ask ‘When can you be finished with a 50 percent probability?’ The word estimation intrinsically holds a probability factor; you have to get that information for the estimate to be of true value.”

    Being a tech-guy I cannot help myself questioning something as scientific as a number, “Why 50 percent?”

    “First of all it tells the developers that it is perfectly alright to be late, actually you anticipate half the features will be late. This way you reassure the developers that it doesn’t mean they have to work extra hours if they are late.”, Søren sips his wine, ” Secondly, it also means half the features are early. This way there is a good chance of the late features being balanced out by the early features.”

    Søren draws again.

    “If you try this out, you’ll be surprised at how short the new estimates will be. In theory a 90 percent probability estimate is about twice as long as a 50 percent estimate. But to get such short estimates your team needs insight into this way of planning. And the plan has to be transparent. Your developers will need this insight to understand the importance of letting go of a feature once it is completed; instead of keep polishing it and delaying the delivery.“

    The bottle of red wine is almost empty. I feel sober.

  • mfp's two cents

    Version control for everyone

    • 3 Comments
    With Dynamics AX 5.0 there is no longer an excuse for not using a source control system when developing in MorphX. The version control integration options in Dynamics AX 5.0 both cater to larger development organizations by seamlessly integrating with Visual Source Safe and Team Foundation Server, and to smaller development teams who cannot afford the additional overhead of these larger system with a new, simple, yet powerful, version control system: MorphX VCS.

    All 3 flavours enable check-in/check-out/undo check-out/change history/change descriptions/quality bar enforcements etc. Using a version control system can dramatically improve the quality, predictability and productivity of your MorphX projects.

    This channel 9 screencast gives a preview of the version control system integration options in the next release of MorphX - the IDE of Dynamics AX. It shows a side-by-side comparison of the integration options with Team Foundation Server, Visual Source Safe, and MorphX VCS. The last half of the screencast gives a demonstration of MorphX VCS.

    Finally I want to wish everyone a "God Jul" (as you say this time of year where I live.)

  • mfp's two cents

    Dynamics AX 4.0 Meta Model

    • 0 Comments

    If you are a new developer and is trying to ramp up on AX, this might be a post for you. In MorphX (the IDE for AX) you do model-driven development. This basically means you create new elements of certain concepts, decorate them with properties, and wire them all together. Naturally there will be requirements to your features that cannot be expressed in the model, in these cases you have to resort to writing X++ code.

    Let's return to modeling. In the AOT (Application Object Tree) you will find a lot of modeling concepts, such as Forms, Tables, Extended Data Types etc. The AOT is quite good as a dictionary of concepts, but how do they relate?   For Inside Dynamics AX 4.0 we created the below overview diagrams to answer this question. After the book has been through editing the diagrams were chopped up. This gives a better details view, but the overview was lost. But not anymore. :-)

    Read each arrow as "using". For example. A Menu uses Menu Items. A Menu Item uses a Form. A Form uses a Table. A Table uses Extended Data Types. And so on.

    I've attach a Microsoft Office Visio version of the diagrams to this post as well for your convenience.

    The win client version:

    The web client version:

  • mfp's two cents

    Late night discussion on software development #1: Continuous publishing

    • 3 Comments

    “So tell me”, I start, “when was the last time you used a help system?”

    Søren pours himself another glass of red wine and leans back in his armchair. He is silent for a while. “What do you mean when you say help system?”

    I open my mouth, and close it again. It always amazes me, when I realize the depth of such a seemingly naïve question. My immediate response seems too narrow. I have to break out of my standard way of thinking. A help system is not just a part of a larger system that helps you when you are stuck. It is even more than this. What comes out of my mouth is: “A help system is a system that helps you accomplish your tasks.”

    “In that case I use help systems daily”, Søren proclaims.

    “Really? I thought you already knew all the answers.”, I cannot resist the temptation.

    Søren smiles, “You are also a developer, how do you manage to get anything done without a help system?”

    Apparently Søren is into one of his moods where he answers all my questions with a new question. I sip my wine, take a deep breath and start to elaborate. “As a developer my work is quite dependent of the phase my project is in. Let's look at my favorite, the implementation phase. While writing code I never press the F1 button. I have worked with my current code editor for so long, that I’m fully aware of what it can and cannot do for me.”

    Søren says: “So you have turned off IntelliSense?”

    “No way – I don’t even know any developer crazy enough to do that. Actually I don’t even know an code editor that allows you to turn off IntelliSense.”

    “Please go back to your definition of a help system.”

    It dawns on me. Help system are more than just F1 help. It is anything that enables me to do my job. “Ok”, I say, “So what other help systems do you use?” I ask. I’m starting to feel confident I will earn more than a hangover from tonight.

    “Well,” Søren says, “as a developer I often need to lookup API reference information. To do that I use the web constantly.”

    “So you actually find any useful information out there? I’ve tried a few times but given up. Instead I browse objects locally searching for something that will satisfy my need.”

    “That is one of the industry’s dilemmas. Users who have been disappointed by the documentation available in the help system, usually never come back. So why bother writing documentation, if it is not going to be read?“

    “Exactly, if the documentation isn’t there, then there is no point in looking.”

    Søren continues, “The users also suffers here, instead of looking for information where it is obvious they eagerly jump into the haystack looking for the needle. How can this destructive habit be reversed?”

    A simple question, I think to myself. I answer: “Well, if the software providers just wrote the documentation we need, we wouldn’t have the problem.”

    Søren promptly replies: “The question to ask is: How do you know it is not already there?” I feel like I’m being maneuvered into a corner. “When I installed my environment about 2 years ago, I browsed through the reference documentation, and it was primarily empty placeholders.”,  I pause to think about what I just said. “Naturally these placeholders might have been populated in the meantime.“ I make a mental note to  reserve some time on Monday morning to give the online documentation a second chance.

    Søren finishes off his glass of red wine. He looks content.

  • mfp's two cents

    Going to Copenhagen?

    • 1 Comments
    With the first Convergence on Danish ground just a few weeks away, you may be planning your trip to Copenhagen these days. While I have no intentions of opening a traveling agency, I do hope you will have a pleasant stay in the city where I was born, and have lived my entire life.

    Often while I'm away on business trips, I spend lots of time searching for local information - and often I end up bringing clothes that doesn't match the local weather, find myself eating at what-ever-restaurant-I-pass-by, and in the plane going home realize I missed the event-of-the-century just next door.

     

    To make this Convergence the best total experience for you, do yourself a favor and visit the the site aok.dk (in english) (Alt Om København - Everything About Copenhagen). It contains all the information you'll need during your stay in Copenhagen: Hotels, Maps, Restaurants, Shopping, Flight information, Weather, Transportation, Sight seeing, Events, Currency, etc.

    For the record, I'm not affiliated with aok.dk or the renewable energy industry - the wind turbines will be your first and last sight of Denmark, if you remember to look out the windows of the plane.

    I hope you'll have a wonderful stay in Copenhagen - see ya at Convergence.

  • mfp's two cents

    New AX Developer Topics on MSDN

    • 1 Comments

    I just received the following great news of progress from our Content Publishing team. Make sure to check it out: 

    The SDK team publishes updates to the existing Developer Documentation every month. Since the release of Dynamics AX4.0, they have added over 5,500 new topics to the online help available on MSDN. These new topics include information about classes and tables, creating and customizing forms, the unit test framework, the reverse engineering tool, the Code Access Permission framework, development best practices, and database objects.

    You can find the new documentation in the Dynamics AX Library on MSDN, and you can download a list of the new topics from the Microsoft Dynamics AX 4.0 Documentation Updates web site.

  • mfp's two cents

    AX Developer Center on MSDN

    • 2 Comments

    AX Developer Center on MSDN has been live for a while now.

     

     

    We have added a few redirects to make the site more accessible:

    http://msdn.com/ax 

    http://msdn.com/axapta

    http://msdn.com/dynamicsAx

    http://msdn.com/dynamics/ax

    If you are looking for developer documentation on AX and haven't visited this site yet, you are doing a disservice to yourself!

  • mfp's two cents

    Compiler warnings - and so what?

    • 4 Comments

    Every so often I find myself in a heated debate on what the quality bar should be for the code in the solution we are working on. This is an important debate, and for the project's success it should not be down prioritized. The quality bar may vary from project to project: If you are developing an internal tool for your team, you will have a completely different quality bar, than if you where writing software to control a spaceship. So in reality it all depends on the project you are working on. The important thing is to lock down on a quality bar and have all developers buy in and conform.

    A part of setting the quality bar for a project is to determine whether to treat warnings as errors. Warnings are an intrinsic part of the tools developers use everyday such as compilers, FXCop, X++ Best Practice Check, PreFast and StyleCop. And for this reason you can have a good, sound, opinionated and often long talk on this fine topic with almost any developer you may cross on your way.

    Being a devoted advocate for improving the code quality across any project, I want to share the following general considerations (courtesy of Ryan Harlicker) with you on why to treat warning as errors:

    1. They just look bad
      If your consumers are able to run the same tools as you are, and thus detect the same warnings, that you've chosen to ignore, it makes you look sloppy. For X++ code this is the case.
    2. Most warnings are really the tool reporting an error
      Most of the time a tool reports a warning it is really an error, but the tool cannot prove it. It is then reported as a warning so a human being can verify the issue and take appropriate actions.
    3. Too many warnings effectively means no warnings at all
      Warnings tend to breed exponentially.  It is best to deal with them at the time of creation as that person has the most context and knowledge of the right thing to do with the warning. If they aren’t handled right away then the knowledge barrier and the fact that they have always been there suppresses the urge to do the right thing and fix them (or suppress them if they are by design).
    4. They are there for a reason
      The warning detection code in the tools didn't come out of thin air. At some point in time someone felt strongly enough to invest time and money in improving the tool to report a warning. At the very least the reasoning for ignoring them should be well understood and not just ignored because they are a warning and not an error.
    5. Your project may become successful
      Even when you are working on a project for a small audience with a high level of tolerance for bugs, you may eventually be in a situation where your project evolves and will reach a broader audience. As the quality bar goes up, so does the cost of fixing warnings. Fixing them right away is cheaper than fixing them later.
    6. Hate to say I told you so!
      Have you ever been debugging a nasty problem for hours, and a split second after you finally reach the Eureka! moment, you realize you were already warned about the problem well in advance? You had just choosen to ignore the warning reported. Personally, I just hate when the tools laugh at me.

    If you are an X++ developer you can learn how to resolve X++ Compiler warnings here.

    If you are working on X++ development, but cant' figure out how many X++ Compiler warnings you have, you should read my blog post on AOT Metrics.

Page 15 of 19 (190 items) «1314151617»

mfp's two cents

...on Dynamics AX Development!