mfp's two cents

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

    Erik and Anni goes to Hollywood

    • 1 Comments

    First episode of Erik Damgaard's new endeavor is now available.

    http://www.kanal4.dk/erik_og_anni_goes_to_hollywood/

    (in Danish)

    Best wishes from here.




  • mfp's two cents

    Writing less code: The "else" statement

    • 17 Comments

    Source code is written once; and read over and over again. So make sure it is easy to read and understand.

    I keep seeing a poor coding practice. I see it in production code, in test code, in X++ code, in C# code, in C++ code, in examples on the web, when interviewing candidates. I see it where ever I look. It is a practice that adds unnecessary complexity to source code, it make the source code harder to read, and harder to write. And what disturbs me the most is, how easy it is to avoid.

    Take a look at this simple code:

    boolean isNegative(int value)
    {
        if (value<0)
        {
            return true; 
        }
        else
        {
            return false;
        }
    }  
    The "else" statement is completely superfluous. This rewrite does exactly the same, and is easier to read:
    boolean isNegative(int value)
    {
        if (value<0)
        {
            return true; 
        }

        return false;   
    }
    Yes; the compiler will optimize the "else" statement away - but that is not my point. The compiler can easily see through the weirdest constructs. I (and most other human beings) cannot. Granted; every developer worth his salt should have no problem understanding both of the above implementations. However often the requirements are more complex.
    int foo(int bar)
    {
        if ( /*expr1*/ )
        {
            throw /*some exception*/; 
        }
        else
        {
            if ( /*expr2*/ ) 
            {
                return 1;
            }
            else
            {
                if ( /*expr3*/ ) 
                {
                    return 2;
                }
                else
                {
                    if ( /*expr4*/ ) 
                    {
                        return 3;
                    }                
                    else
                    {
                        throw /*some exception*/;
                    }
                }
           }
        }
    }
    Or, this slightly better version: 
    int foo(int bar)
    {
        if ( /*expr1*/ )
        {
            throw /*some exception*/; 
        }
        else if ( /*expr2*/ ) 
        {
            return 1;
        }
        else if ( /*expr3*/ ) 
        {
            return 2;
        }
        else if ( /*expr4*/ ) 
        {
            return 3;
        }
        else
        {
            throw /*some exception*/;
        }
    }
    Could be simply rewritten as:
    int foo(int bar)
    {
        if ( /*expr1*/ )
        {
            throw /*some exception*/; 
        }
        if ( /*expr2*/ ) 
        {
            return 1;
        }
        if ( /*expr3*/ ) 
        {
            return 2;
        }
        if ( /*expr4*/ ) 
        {
            return 3;
        }      
        throw /*some exception*/;
    }
    Never-ever-under-any-circumstances-for-any-reason-what-so-ever write an "else" statement if the preceding block unconditionally returns or throws an exception.

    Now I got it off my chest :-)

  • mfp's two cents

    Upgrading to Microsoft Dynamics AX 4.0 and Microsoft Dynamics AX 2009 @ Convergence 2008

    • 2 Comments

    Deepak Kumar and myself will be hosting a session on the upgrade process at Convergence in Orlando next month. I hope to see you there. 

    Upgrading to Microsoft Dynamics AX 4.0 and Microsoft Dynamics AX 2009; 3/13/2008 10:00AM-11:00AM; W204

    This session will take you through the end-to-end flow of upgrading from Microsoft Dynamics AX 3.0 to Microsoft Dynamics AX 4.0 and Microsoft Dynamics AX 2009. You will see an overview of the code upgrade as well as the data upgrade process along with recommended best practices. Examples of the improved upgrade documentation, with a focus on the implementation guidelines that come with a dedicated section for upgrade, will also be covered. This session will also include tips on performing data upgrade and code upgrade more efficiently and effectively. Additionally, you'll learn tips on the extra steps needed to upgrade if you've extended your solution. This session is designed for partners and customers who are planning to upgrade or would like to learn more about a Microsoft Dynamics AX upgrade.

  • 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.

Page 14 of 19 (183 items) «1213141516»

mfp's two cents

...on Dynamics AX Development!