Skip to content
* / softthoughts

Reading NLog log files with LogViewPlus

Reading & understanding log files can be a time consuming & difficult process, but it is a necessity to communicate the state of the application and if needed to fix bugs.

A nice tool I recently discovered is LogViewPlus (https://www.logviewplus.com/). The tool is described as :

  • Fast and easy to use
  • Has built in filtering and analysis tools
  • Built specifically for reading application log files
  • Works with live data by tailing the log file
  • Auto-detects logging formats
  • Visually engaging to help you find issues faster
  • Supports viewing large log files
  • Similar to Tail and Grep, but for Windows
  • Fully supported

What makes it extremely useful for me and makes it my number one choice compared to similar tools is :

  • Its filtering capabilities
  • Layering the filtering on top of eachother & save it as a workspace
  • The concept of starting & stopping a session. This makes it easy to have a clear log view for a manual self-defined session you start & stop.
  • Clean UI with an easy full screen option
  • The support & documentation around the tool is very good.

LogViewPlus is a tool I can’t miss anymore.

* / softthoughts

Reverse Logistics & Waste Management Solution 2wayLogistics for Microsoft Dynamics Ax 2012

After 2 years of research and development I’m proud to announce on this blog that our company (AXi SoftWorks) released our Reverse Logistics and Waste Management solution 2wayLogistics for Dynamics Ax 2012.

2wayLogistics is a complete solution for reverse logistics and waste management in the environmental
enterprise. It is refreshingly different and empowers reverse logistics and environmental companies to outsmart competition. 2wayLogistics is our primary focus, and is developed in a team with more than 15 years of industry and software implementation experience. It provides a new standard software solution for waste & recycling companies, and production & services companies with reverse logistics business processes.

For reverse logistic customers, partners and consultants,and all interested check out the product at our site:

http://www.axisoftworks.com/axi/products/used-products-management

* / softthoughts

Application Lifecycle Management (ALM) for Dynamics Ax Part 2

After a long time of iteratively extending the Dynamics Ax 2009 ALM tool, we can say that the first final and full deployment of the Dynamics Ax ALM tool in the production environment has been a succes. Our customer went live in the end of last year. More than 100 users and an IT team are daily using a Dynamics Ax environment where an Ax ALM tool supports their:
– Issues
– Business/Features requests
– Testing
– Resource planning
– Release planning
– Ax Module dependencies
– Ax Software development artifacts
– Ax Application building for each release
– Ax Bug fixing
– Ax Software solution deployments
– Detailed traceability from issue or request to solution deployment

At least two things that all these points have in common is their ease of use and the traceability that justify and allow an easy follow up on every activity or artifact. This is mainly made possible because of the deep integration with Microsofts Team System.

Next week Microsoft will introduce in the Ax technical conference 2011 their improvements in next version of Ax, and this also in the area of Dynamics Ax application lifecycle management. In some areas where we made specific ALM development to support our customer and general ALM requirements, we hope to see that Microsoft future Ax version will provide nice enhancements, partially based on Team System. We are looking forward to that!

For more information about the ALM tool please feel free to contact.

* / softthoughts

Application Lifecycle Management (ALM) for Dynamics Ax

Application lifecycle management (ALM) can be described as an overall technique to provide and support a certain level of implementation, system and business qualities. For these qualities to reach a minimum level of satisfaction it requires a set of tools to ease the road to assur it.

Because a Dynamics Ax implementation environment has some gaps related to available tools supporting a high level of Dynamics Ax ALM, I want to describe here shortly the problems we face in my current project and others can face too and mention areas we are tackling with our own designed tools. With these tools and the standard available tools we try to support the enterprise in their attempt to setup a strong quality generating implementation methodolgy which incorporates ALM at a high level. 

ALM tools in Dynamics Ax

The domains through which ALM tries to reach quality are: Requirements management, Feature management, Architecture and Design modeling, Project Management, Change management, Configuration Management, Build management, Testing, Release Management, Software Deployment, Issue management, Monitoring and reporting, Workflow… (see for more Wikipedia)

For the Dynamics Ax application there is a nice ALM toolset to support the domains but they are still in its basic/essential phase. Currently the toolset contains:

  • Unit testing frame
  • Best practice validation frame
  • Version control frame (Team foundation server)

These tools and frames are mainly centered around the coding activity. Some others are:

  • Data upgrade script management
  • Reverse engineering (UML diagram generation)
  • Upgrade reports

which leave more the realm of coding but are still far from providing very valuable implementation, system or business qualities through application lifecyle management.

Tackling Dynamics Ax ALM tool gaps with Team System

Currently the big tool from Microsoft that tackles a lot of these areas is Team System. Aspects as Requirements management, Feature management, Project Management, Change management, Issue management and Version control from Team system can be easely combined with the ALM tools in Dynamics Ax. Companies that have a solution based on Dynamics Ax certainly have an intention to fill up the ALM gaps in Dynamics Ax and build sometimes some extra little tools or use the above mentioned aspects of Team System.

Standard ALM tool gaps for Dynamics Ax

With the current state of the art around Dynamics Ax we still face some ALM aspects that can’t be supported relatively directly with available tools.

One important aspect for every architect is the validation of the Architectural requirements like eg module dependencies. These are certainly important to manage when you are building a product line or your application is in an agile environment that constantly demands changes. Dynamics Ax has no build in architectural validation tool and neither Team system can help in this area.

When additions for the Dynamics Ax application are required, the development mostly happens inside Ax projects. These are a grouping of application elements which the developer changes or creates for providing a solution. When the task of the developer is done this project needs to be deployed on other environments. Dynamics Ax tools don’t exist to ease and trace this Software deployment aspect or follow up relatively safely/accurately related statuses like accepted or task closed. 

Traceability during the entire application implementation can help in providing quality on all levels. Traceability can be related to the evolution of the different Ax project builds that were deployed on all environments, to the application elements that were changed for a specific request, to the features or bug fixes that demand the development task… Standard Dynamics Ax tools don’t provide currently this level of Feature management, Change management and Issue management.

These gaps and others (Development task management, Application auditing/monitoring, Release management…) demand at my current project a solution. In the project we are setting up an agile development environment in which we try to provide an implementation base for the following years that incorporates a high level of ALM possibilities from the beginning.

* / softthoughts

The future embraces EDA

Event driven architectures (EDA) will come in the following years more to the front in distributed applications and their architectures. Some think they are the next step after SOA, others have the idea that the 2 (reference) architectures complements. Eitherway, in todays distributed applications some concepts of EDA are already used, although mostly the defined/used software delivery cycles don’t position them very explicitly in a good structured quality generating delivery process. Contemporary SOA is becoming a mature technique and a new standard in enterprise architectures. The possibilities are that EDA undergoes the same and delivers some extra or other quality characteristics than contemporary SOA. It can bring the continuous seek to unification intra and inter applications and/or enterprises to a new level. What EDA certainly shall do is bring our designs closer to an inherent attribute of nature: send and move on.

* / softthoughts

Ax Runbase patterns for RPC reduction

The Dynamics Ax performance team published patterns that can be interesting to solve performance problems in case maybe some of the following issues arise.

Issue #1:
The #CurrentList macro is used for both SysLastValue and Pack/Unpack serialization.

Issue #2:
Non-packable objects are created on the dialog which runs on the client, but used on the RunBase derivative class which is running on the server.

Issue #3:
Client interaction is being performed in the main method.

Issue #4:
Significant server interaction is being performed on the Dialog or in the dialog method.

Issue #5:
The RunBase-derivative class needs to load data from a user-specified file that exists on the user’s client machine, but the class’ run method will be executing on the server.

In this paper they describe one general pattern and some specific patterns.

* / softthoughts

Effectiveness and getting there efficiently

Dan Rawsthorne wrote an interesting post about “Scrum is Effective, not Efficient“. I don’t follow fully so i made some comments. I write it here again because it has some aspects that are related to software architectures and which are important to produce quality. To have the full context of this post it is important to read Dan’s post.

Dan says: “The more feedbacks you have the more effective you’ll be… ”

I think the amount of feedback is not so important to determine the  effectiveness, what is more important is the quality of the feedback which is aligned with business goals. Can’t a few good feedbacks be enough to know how effective you are? You can specifiy some quality scenario’s for measuring your effectiveness. Ofcourse lines of codes or function points are to vague and don’t tell much business/product relevant effectiveness. Thereby, finding the right feedback through quality scenarios can help to reach the effectiveness efficiently instead of going for a lot of feedback.
Maybe it is not easy to specify precisely what needs to be done, this is where agility comes into the picture i think, but in general every project has some clear business (case) goals and for those, quality scenarios can be provided to measure the overall effectiveness.

Dan says: “In order to be efficiently agile, you would need to have feedback loops that got you the answers you needed as fast as possible, and have as few feedback loops as possible. And we don’t know how to do that, now do we?

If you can specify how to be effective, and you say that agility is effective it means you can specify effectiveness, than you can specify a way to reach it efficiently. I think too that agility is effective and i would measure it with quality scenarios. This also gives the possibility to have a reduced set of feedbacks related to the Q scenarios and allow us to get there efficiently because we know our goal.

Dan says: “…if you can’t produce the right product every time (or virtually every time) then don’t start adding efficiencies to your process.”

Why can’t you add efficiencies in your inspect and adapt cycles?  Rethinking and implementing the way to produce a powerfull effect can also ask for incorporating some efficient steps.

Dan says: “waterfall is efficient — agility is effective”.

I think if you say it is efficient, it means that it also has to be effective.  Saying something is efficient means its result is effective.  So in the conclusion it sounds to me that waterfall is the ultimate way to go, which i doubt and probably also not the one of Dan.