Missing type map configuration or unsupported mapping. Mapping types: IDataReader -> List`1 System.Data.IDataReader ->

You will often find this error when converting IDataReader to POCO. There are 2 resolutions here –

if you are using Automapper 4.0 or above, check MSBuild probably have deleted Automapper.Net4.dll in bin folder, if it is, restore it.

Second, IDataReader is unsupported from Autoamapper. you can use below 4.0 (or 3.1.1), which supports IDataReade, unless you are not using specific version features.

Invoke or Run IIS Express x64 with VS2012.

For some reasons, you may have to run IIS Express x64 from VS2012. For later versions, it is automatically instantiated, however in case of VS2012, it isn’t. And there is no way Microsoft provides any patch or upgrade.

Although there is untestable hack or trick which did work for me.

You have to modify registry to invoke or run IIS Express x64.

Create batch file (*.bat) and put below code.

reg add HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\WebProjects /v Use64BitIISExpress /t REG_DWORD /d 1

VB6 after long time…

Yeah… Even its a surprise, VB6 still rules the world and rules my life.. I cannot say No to VB6 jobs – I don’t know why and thats why I got engaged with one of the VB6 project which requires some fixes and I love to take this opportunity.

All though – world has changed from XP to Win 7 to Win 8 and now Win 10, VB6 application and development with support still rules in some part of the world. It has been days that I’ve been trying to port VB6 environment on Win7 64 bit, but some or the other case it failed. Surprisingly, it loaded on Win10 without much issues and after some tweaks. However, it was too difficult to load it on Win7 x64 bit … Not sure why. Nevertheless, managed to load it on machine.

If you have some issue, just share it across I may help.

After long time…

I know I have been out of writing blog lately, there has been lot of stuff I went through since my last post.

I will promise I will keep this blog updated as lot many things are going into my life at the moment.

#Enterprise #Architect with/and #Agile

An enterprise architecture is a disciplined approach envision to take business from current stage to next stage. It boils down to making sure an organisation’s systems harmoniously work together to meet the business objectives and different views. It is a process of developing capabilities, defining principles and frameworks which helps during implementation.
It is often observed, architecture has slowed down the process of development teams, because they carry bigger picture and had a long-term vision. On the other hand, engineering team have evolved, and they’ve evolve a lot more quickly than architectures. This is because challenges and lessons learned from past deliveries have forced them to evolve and act on business changing needs. I’ll skip other software development cycles for the sake to keep this short. In recent years, agile has improvised the way the software has been delivered – by keeping it simple to deliver what is asked to, deliver in chunks rather than big-bang, deliver what it is required against what was required, easily mitigate the risks, early assessment, dealing with changing requirements. This has helped development to pace up with business, yet with quality delivery.
It is necessary to understand that the starting point when architecture starts to meet business expectations, may have changed at the time they finished. The similar approach to deliver has to be taken by architecture. Today’s architecture cannot deliver business vision based on discussion held few years back. EA should visualise how the process of delivering the facilities to engineer team should streamline and address the ever changing needs and re-evaluate the decisions as requirements change. Although, we are talking about the vision and delivery of vision, the key aspect is how EA can improve their deliverables and keep with the pace of business needs, w/o compromising their goals, principles, guidelines, and meeting common issues. It’s time to transition ourselves naturally and have more engagement with the projects. This will bring more agility in the process.
It seems Agile methodology of delivery projects can help EA to assess the key goals and drivers from time to time. It is tricky how the integration will help so that EA should not over-engineer and delivering what business is looking for and changing their approach based on change requirements. It is important to understand how Agile team will cope up such deliverables when it is not a monolithic project delivery. It’s time to look beyond the horizon and accept the key challenge of ever changing and define the strategy to mitigate this risk. This could reassess the designs from time to time, follow best practices, introduce iterations within the architecture delivery phases, bringing more agility, introduce or co-work with agile model driven development focusing on model, vision, and feedback.

From #developer to #architect – Step 1

So, you’ve decided to be an architect? What makes you think to get into this stream – love of technology, passion to build solutions, you hate your architect and you can do well more than him/her, etc. Anyway, since now you have decided (or reading for some sake) let me, at least put some basic information, what you should know when you are aspired to be an arch. I’ll try to keep this as simple as it should be, consider this article as a baby step or first step.

Rule # 1: Inputs and deliverable – Very first you may have observed that architects often start their answer with “it depends”! Yes, that’s correct and it is! When you are developer, you know there’ll be only single approach to a problem – meaning to open a File Dialog to save file from your application, you’ll use single line syntax using your favourite programming language – FileDialog.Open(); An architect has to consider various factors and inputs before coming up with answer, hence “it depends!”. Deliverables are what, as an architect, you will deliver. Unlike coder, where you deliver code (module, database, set of classes, etc.), the deliverables are often documents and artifacts. Depending on audience, documents and artifacts delivery will vary.

Rule # 2: Fundamentals – Strengthen your fundamentals. By now, you’ve invested your time and efforts in development. Round the clock, burned your weekends, gained calories, compromised your health (and hair). Being an engineer, you should be aware how things work! By things, I mean – anything what you are familiar with – language, database, programming, etc. This will help you to justify what to use, when.

Rule # 3: Keep learning – by that I mean, be learner. Don’t refrain or limit yourself to specific technology or concepts. This will help to widen your thoughts and help you to choose when to use, what! 

Rule # 4: Good listener – Developers are impatient. They generally get into coding without much thinking solution’s cons. I would suggest to be good listener and then react. Start practicing drawings on paper. This will help in visualising what is being said.

Rule # 5: Terminology – often architect speak business language which is familiar to business. Yes, you should start thinking from business view like how your earlier work has helped to the business and try to visualize it in a bigger picture.

Rule # 6: Visualize – Start visualizing the end product/software/business solution well before it has been realized. Be analytical, how particular business requirement will solve through software.

Rule # 7: Communication – Most importantly, be communicative. Unlike in development zone, this soft skill will help you to grow from all dimensions. As an architect you will be dealing with different stakeholders – project manager, business, analysts, developers, operations, etc. hence, you should be communicative and that too, precisely and to the point.

Rule # 8: Some managerial skills – Get the work done from your peers, understand the strength and weakness of your team and based on that react and estimate the time required to develop your architecture. Be a good planner, good estimator.

Rule # 9: Patterns and practice – know the patterns that are solution to common problems. This will help not only in reducing the efforts but also improves quality architect delivery

Rule # 10: Books – these are man’s best friend. Keep reading, understand the concepts, patterns, solutions, common practices, guide, common terminologies. This not only will help you to grow, but also widen your boundary of thinking.

Mind map for TOGAF v9.1

Few months back, I appeared for TOGAF v9 exam and successfully cleared it. Although it was tough by itself, but my experience with earlier projects helped me to understand its concept. For those who haven’t been fortunate, I would suggest to look for and take help from mentor. This really helps. Many of us, aligned it with Solution Architect role or even try to align it with technical experience, although, to some extent, it is true, but as a whole, these are just the piece of big puzzle. 
In short, TOGAF is about applying its ADM development method on a given state of requirement leading it to next stage, and at the same time – build enterprise’s capability, and maturity. I believe this can be applied on any business requirement or problem, where it involves the progression from one (current) state to another (advanced/more mature) state.
Although during my exam study, I did took help from different sources including self-study kit from The Open Group. Some of noted I created my own during the course. Mindmap, is one of the note I keep referring, as and when I need some help for a quick glance or help.
It was created using FreeMind, and I would like to share it for an aspiration, inspirational and reference study.
Hope it helps you.

Download from here: http://1drv.ms/1WvYO4N

Follow

Get every new post delivered to your Inbox.

Join 210 other followers

%d bloggers like this: