mfp's two cents

...on Dynamics AX Development!
  • 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.

  • mfp's two cents

    Articles on X++ development

    • 0 Comments

    While digging in my archives to service a request from a co-worker I stumbled across a few articles I wrote for Damgaard Technet. Those that are still valid, I've polished a bit and made available here.

    Behavioral information messages

    How to use a form tree control

    Delaying method calls

    The user friendly Infolog

    Showing operation progress

    Global variables

    I hope you find them useful.

     

  • mfp's two cents

    New blog from the X++ compiler team

    • 0 Comments

    Make sure to check it out: http://blogs.msdn.com/x/

    They already got a cool post on how to implement the observer pattern in X++.

  • mfp's two cents

    Microsoft Dynamics AX Developer Center: Your one-stop resource center for AX Development

    • 1 Comments

    This is the lastest of great AX resources becoming available. This site is an umbrella site for existing information. It ties together news groups, blogs, training materials, downloads, online documentation, and much more.

    http://msdn2.microsoft.com/en-us/dynamics/ax/default.aspx

    It didn't take me long to realize this should be my default home page for my iexplorer - this is a site I'll be visiting a lot in the future. Make sure to check it out yourself!

Page 15 of 19 (187 items) «1314151617»

mfp's two cents

...on Dynamics AX Development!