One of the choices a customer interested in Microsoft Dynamics NAV must definitely make is the choice of the database platform. With NAV, there are two possible options: so called native database server, which is not really officially called that (the official name is Microsoft Dynamics™ NAV Database Server), and Microsoft SQL Server.
Policies are sacrosanct. Every company has them, and when implementing ERP systems policies do come in the way. That’s the way we do it ’round here since forever, is heard rather frequently, but a simple question why can leave a big question mark hang unanswered.
There was an experiment…
In Croatia, most of roads resemble battlefields. They are so full of holes and patches from all kinds of repairs over time, that they have to re-pave them every five years or so. It is an awful waste of taxpayer’s money, and makes you wish for the world of Jennifer Government to come be. Anyway, as soon as they re-pave the roads, not a week usually passes before they come again, with jackhammers and heavy machinery of all sorts, and start drilling away, blocking the road in process and causing mass-frustration, just because some wacko has suddenly remembered that it would be nice idea to pass the optic cable underneath, or some valve started leaking.
Development is an important phase of implementation of a highly-customizable ERP system, such as Microsoft Dynamics NAV, and that’s why I put a lot of emphasis on development, specifically on coding part of it. I’ve tried to cover a few do’s and don’ts of coding, but so far I’ve left one of my favorite clay pigeons out: hardcoding.
If you want me to define hardcoding, I’d probably put it something like this: hardcoding is the ugliest possible form of laziness, incompetence, ignorance, indifference, carelessness, or any combination of the five, which in short-term makes my toenails curl up, and long-term leads to poor and unmaintainable systems and unhappy customers.
When I posted my last relevant post on this blog, I’ve got a comment from infonote (a visitor) how bad it was that Microsoft Dynamics NAV can’t use a versioning system. Well, as the matter of fact, it can.
One of the nice things in NAV is that at any given moment, the development environment is just a Shift+F12 away. When you are a single developer on your team or on a project, this keypress is your best friend. But if there are other people on your team pressing it with an agenda, then this keypress might as well be a combination made in hell.
I’m still in Vegas, and this city is crazy. But it’s funny, us people in IT have a thing or two to learn from these people in gambling business. We have all been hearing from our customers how they want their systems reliable, available, and so. Well, what I’ve been seeing here for the past two days is a highly-available 24/7 service with full redundancy and failover clustering all in place. There are roulette and blackjack tables and slot machines in every free square foot, so it’s pretty darn scalable, too. There is zero downtime, entertainment never stops, and that’s pretty much the reason I write this post now, instead of sleeping. I almost feel the music is louder by the minute, probably proportionally so to how sleepy I am. I’m too old for this sh*t.
Although I really planned, and I really wanted to, I don’t think I am going to post anything useful in next few days. I spent last week in Seattle, attending TechReady conference, and now I am taking three days off – in Las Vegas.
As the matter of fact, I’ve just arrived, have a semi-splendid view of The Strip from my hotel room, which has much more drawbacks than benefits, so when I give it a proper thought, with all this noise, music and jet engines blowing my ears away, I’m probably going to stay awake and produce something anyway. But I promise nothing.
Thanks to everybody on recent comments, I am glad that this blog started rolling, and I hope I make it worthwile for you. Dave was actually the only one who attempted the quiz from the last post, and since he was almost correct, I give him full credit in this post, but withhold the bragging rights. So, congratulations, Dave! 🙂
Stay tuned, for the next thing I am going to post might be really interesting for the NAV development community. See ya!
Few days ago, when I wrote about coding, I didn’t have a slightest idea that at the same time, at the completely opposite part of the globe, Dave was blogging almost about the same thing. It is interesting to know that I am not the only one out there actually worying about code, and how it looks like.
The most common thing I used to hear when I asked bad coders about their code was: “It works, why shoud I care.”
Today, I got an e-mail from a reader of this blog, who asked me to help them with an actual problem on a project. Their customer is a small manufacturing customer in textile vertical. Whenever they calculate consumption, quantities for certain items get rounded to full numbers. Since the items are usually textile, measured in meters, a consumption of 1.27 meters can end up registered as 2 meters instead. Not that it’s something which can’t be overridden manually, but it is pain in the butt, and hey, why do we have computers in the first place if we have to do their job.
Code is boring. It is geeky. And it’s ugly, too. In C/AL it is especially ugly. While contemporary development tools come with all sort of gizmos which make coding easier, such as color-coding, auto-completion, refactoring, etc., C/AL editor seems like having awaken from a thousand-year sleep. Take a look at the color coding: there is none. Or there is, but palette is limited to that of Charlie Chaplin’s. There is some functionality which looks like auto-completion but it is not, and the text editing capabilities make you dream about Notepad at night. But you can look at it from a different angle. C/AL editor is the way it is for a reason: to keep programmers away. It’s the defence mechanism developed over twenty or so years of evolution of the system, to protect the system from rookie knowitall programmers ripping away that stupid Gen. Jnl.-Post Line codeunit and rewrite it the way it should be. With this, we come to Rule No. 1: Know what you are doing.