Dynamics Corner
About Dynamics Corner Podcast "Unraveling the World of Microsoft Dynamics 365 and Beyond" Welcome to the Dynamics Corner Podcast, where we explore the fascinating world of Microsoft Dynamics 365 Business Central and related technologies. Co-hosted by industry veterans Kris Ruyeras and Brad Prendergast, this engaging podcast keeps you updated on the latest trends, innovations, and best practices in the Microsoft Dynamics 365 ecosystem. We dive deep into various topics in each episode, including Microsoft Dynamics 365 Business Central, Power Platform, Azure, and more. Our conversations aim to provide valuable insights, practical tips, and expert advice to help users of businesses of all sizes unlock their full potential through the power of technology. The podcast features in-depth discussions, interviews with thought leaders, real-world case studies, and helpful tips and tricks, providing a unique blend of perspectives and experiences. Join us on this exciting journey as we uncover the secrets to digital transformation, operational efficiency, and seamless system integration with Microsoft Dynamics 365 and beyond. Whether you're a business owner, IT professional, consultant, or just curious about the Microsoft Dynamics 365 world, the Dynamics Corner Podcast is the perfect platform to stay informed and inspired.
Dynamics Corner
Episode 423: Business Central, AL Development, and the Art of Problem-Solving
In this Episode of Dynamics Corner, hosts Brad and Kristoffer engage Marcel Chabot, a veteran software developer and innovator, to unpack his eclectic journey from rocket engine testing to mastering ERP solutions with Microsoft Dynamics 365 Business Central.
Marcel Chabot illuminates the intricacies of AL development, emphasizing its integration with .NET and the creative problem-solving it demands while navigating the challenges of migrating from legacy systems, such as GP. He emphasizes the crucial role of code quality, collaboration, and understanding client needs in minimizing technical debt and enhancing extensibility.
The conversation explores the evolving landscape of programming languages, highlighting the crucial role of ISVs in improving the capabilities of Business Central.
Marcel Chabot advocates for balancing custom solutions with off-the-shelf functionalities to optimize implementation and reduce maintenance costs. This episode presents a compelling blend of technical expertise and practical guidance for developers and business leaders navigating the complexities of modern ERP systems.
#MSDyn365BC #BusinessCentral #BC #DynamicsCorner
Follow Kris and Brad for more content:
https://matalino.io/bio
https://bprendergast.bio.link/
Welcome everyone to another episode of Dynamics. Corner Brad, what is the first word in an English dictionary? I'm your co-host, Chris.
Speaker 2:And this is Brad. This episode was recorded on April 30th 2025. Chris, chris, chris. What is the first word in the English dictionary? I don't know. I'd have to go to the English dictionary and look it up, but today we had the opportunity to talk about that, as well as AL Development, business Central and some cool toys With us. Today we had the opportunity to speak with Marcel Chabot the man of the hour hello, good afternoon.
Speaker 2:How are you doing? Doing great, how are you doing, you know, all things considered, I'm doing well. Well, ten fingers, ten toes, breathing.
Speaker 3:On the right side of the astroturf. That's all that really matters. Is there a right or wrong side? Well, there's the underside of the astroturf. You don't want to be there.
Speaker 2:How do you know?
Speaker 3:Oh, you have a point.
Speaker 2:So yeah, that's. I don't want to get in. I could say so much for that, but I think many may not understand my thoughts on that. But yeah, I don't know which side's the right side. I guess it depends on the day of the week, but not many people have told me about that side, so I really don't know if it's better or not.
Speaker 3:Survey's incomplete.
Speaker 2:Yes, yes, so maybe, well, maybe we could use Copilot.
Speaker 3:Copilot could tell us well, maybe we could use copilot. Copilot, do you think copilot would know I? I don't know. I don't know. Copilot can give me uh input on the afterlife. I don't know if I trust it philosophical for you?
Speaker 1:yeah, it's too philosophical.
Speaker 2:You're correct. And then how do we know if it's correct?
Speaker 3:so we just wouldn't know, right, right so I I've got a new microphone, so if I sound like garbage, let me know and I can turn knobs or whatever it sounds good.
Speaker 2:I so far it sounds good, but you can turn knob. It's turn whatever. Turn knobs if you want to see how it sounds it's got knobs and dials. I've been harassing everybody yeah, all right do I sound like I'm in a closet or what uh, you know some of these microphones. I'm glad with this one I don't have the knobs and dials, but I had the ones with the knobs and dials before and I just didn't understand and there really isn't a clear way to be able to tell no, it's a challenge how it sounds there's always post-processing, there's always post-edit.
Speaker 1:You know, as long as you're clear, you're fine, because there's a lot you can do. So much after the recording.
Speaker 2:And now you can do AI voice correction Right, so that if we need to do some, I'm not saying that's what we do, but I've seen that there's tools now with AI voice correction that you can do some corrections.
Speaker 1:It does help because there are times where we're recording and then the guests, you know, sometimes we don't notice it, but then, like once we get the raw file and it's it doesn't sound really really good and there's tools now. Yeah, it does help me kind of remove all of this stuff and just kind of isolate the voice. It's amazing what it can do now Makes my, my job easier. Nice, nice, I don't think you've ever worked hard, but anyway, do you have ai for that now?
Speaker 2:man, you should be more creative great, but thanks for taking the time to speak with the staff and I've been looking forward to speaking with you, uh, and also it was great seeing you in Las Vegas as well. That was a lot of fun. Appreciate the Uber, you know. It's always nice to when someone can figure out how to use the Uber application when you can't. And also congratulations on your recent Microsoft MVP. And before we get into the conversation, would you mind telling us a little bit about yourself?
Speaker 3:My name is Marcel Chabot. I'm a software developer. I'm the team lead here at the TM Group. I've been doing software development forever and have been in lots of different industries. I've done everything from brewing beer to rocket engines in all sorts of different industries. I come out of test and measurement, where we would rip trailer hitches off of pickup trucks and test all the things. Destructive testing was my favorite because I was young and destructive text testing is pretty exciting when you're just out of college and you get to break things for a living and that was kind of neat.
Speaker 3:I would love that, yeah, but the industry is super volatile and, uh, things went bad in michigan and I moved over to business software and been doing that for 18 years now and it's uh, it's a lot of fun. It's. It's interesting in all the different places that we get to because everybody has finances, everybody has money that's got to come and go. Everybody has a business to run. So you have your CRM systems, your contact management, your finance Everybody has it. So it's something where I get to put my fingers into all sorts of different industries and it's been fun how I've worked with breweries building sensor networks to monitor beer and I've worked with breweries building accounting systems to sell the beer Not the same ones. I've been hoping for that crossover at some point, but it's been really interesting to have both experiences.
Speaker 2:Hopefully you get to experience that and breaking things for a living must be fun, because you get a lot of frustration. It must feel good when you get home. It must be nice and relaxed. And did I hear that you built rocket engines?
Speaker 3:I tested some rocket engines. I did rocket engine testing. How did you test that? It was a bunch of sensors around something called a pebble bed. It's where you blow hot rocket fuel across a bed of ceramic beads, which they call technically NASA hot, and then the fuel combusts and you have to be able to control that. And um, there's a whole bunch of stuff. There's all sorts of phds. I just got the wire sensors and hook up computer software to it and all the phds got to watch these numbers go. Oh, and I'm like, yay, rockets.
Speaker 2:See, it sounds like you had some fun, and with ERP software implementations. It is fun because every implementation is different, it seems like, or every project's different and, as you'd mentioned, you can get into many different industries. Some organizations will specialize and have niche markets for verticals, as we call them, but then there's others that will deal with many different customers.
Speaker 3:I think it's fun. We set a countdown on a new client, which is time till. I can't believe nobody else. You know they're looking at a report. I can't believe nobody else needs this report. The report doesn't exist. Nobody has ever wanted this before. Nobody wants data, this report. The report doesn't exist. Nobody has ever wanted this before. Nobody wants data this way. But for your particular industry, I can see where that's important. But no, you are the first and we start a countdown and everybody, at some point when we're working on an industry that we have never worked in before, ask the question. I can't believe I'm the only one who wants this. Yeah, you are.
Speaker 2:Congratulations. You should start handing out a prize with that. So, working with Business Central and being a, I call you the scientist now, so maybe that will be your new name.
Speaker 3:You're not the first, oh I can't believe someone hasn't called you.
Speaker 2:No, I know, thank you.
Speaker 1:Well, I guess maybe I'll take that nickname away.
Speaker 2:So working with Business Central. How long have you been working with Business Central? You said you made the crossover to software. Have you always worked with Business Central?
Speaker 3:I started with GP. The TM group was one of the first GP consultants. Judy Thomas started with this newspaper ad looking for implementers for this new accounting package 40 years ago. So when I moved over to the TM group it was all GP. But then, you know, gp started to look a little old, at 30 some odd years, and we moved over to the next product in that tier, which was a division at the time just around the seaside AL, to cut over. So 14 years ago.
Speaker 2:Yeah, that was 20. No, well, the cut over seaside to AL was 2018. The vision to business, vision to geez, the vision to dynamics nav was with 2013, 2014. I can't even keep track.
Speaker 3:I'm trying to play this all back in my head yeah, it takes a long time. It's time has flown.
Speaker 2:I know, I know time is valuable and precious, and how quickly it goes by as you get older makes you take a look at what you do with your time and value a little bit differently. So do you work with development for business central?
Speaker 3:strictly. My group is strictly development. That's my focus and our accounting team, our functional team, bless their heart, has for years tried to get me to get credits and debits straight. But I still look at credits and debits from my point of view and it's backwards because accounting credits and debits are backwards from personal finance and I still get them backwards all these years later and they're they complain. I'll never be an accountant and I thank them for the compliment and get back to my work.
Speaker 2:Yes, as long as the numbers add together properly. That's the important thing that's the important thing two plus two should equal four. So you work with the development and and AL development's a lot of fun. Business Central development's a lot of fun. You get to do a lot of great things Maybe not some rocket science type things, but maybe you can as well.
Speaker 3:Coming out of GP, where you got not one but two user definable fields, and moving over to Business Central, where I can define fields all day long.
Speaker 2:It's such a great switch up to to a much more dynamic accounting system and uh it is great and uh, through conversation, some of the things you like to do, you like to, I guess, uh, test the limits of some development as well, too, correct I?
Speaker 3:do. There's a uh, there's a yearly I guess it's a competition. It's more of a nerd flex called the uh the advent of code and uh, there's 25 two-part problems that you can try to solve and it doesn't matter what language you do it in, because it always comes out with a number when you're done. And I tried to solve as many as I could in uh and I got through week eight and then things started getting really weird. Some of the answers require recursion and that worked for a while and then Business Central just said no, the processing requirements were really high. One of the answers was something called a 40-year transform. Where it's it's complex math on repeating things.
Speaker 3:And um, I tried to do a 40-year in business central and it just noped right out. And why would it do a 40-year? It's not the kind of math. There's no accounting that ever would need that. But getting through eight weeks, which is 16 problems, before it gave up I thought was pretty good. I bet there's people who could push it farther than me. There's a lot of really smart people out there and I bet somebody could solve all of them in there. But at some point I hit the point of diminished returns. I had some really neat things. I learned about the limits of BC and as they add new features in, it'll be more capable later.
Speaker 2:There's NET underneath, so yeah, so they expand the library. Well then, depending upon which version you're using, if you're using the on-premises version, you could reference some assemblies and also maybe use a control add-in.
Speaker 3:That might be cheating, though well, yeah, my goal was to do it in al. At any point, I could have kicked it off to an azure function. Did the work in an azure function return the answer?
Speaker 2:no, I understand. I thought about that after I said that and said then it's not al, you're just using al as a gateway to something else to solve the problem with the processing.
Speaker 3:But that may be the point that AL has a limit and stop doing crazy stuff in AL and kick it out to something outside that will do the work for you.
Speaker 2:Well, I think that is a good point, because I think everything has a purpose and you use the appropriate tool for that, for the job.
Speaker 1:It's a natural path't it like to to to go beyond outside of al for a different function it is and it's knowing if.
Speaker 3:If al is the only tool you have, then everything looks like an al problem. And uh, early in my development career, you know, I I knew a handful of languages. I was going to solve every world problem in my favorite language of the time and wrote some really bad code that I'm afraid might still be out there in the world. And then as you, as you get older and you do more stuff, you realize, hey, I'm just no, this isn't the right way to solve this.
Speaker 2:Moving on, yes, no, it's, it's no. You laugh because you said some really bad code. But I think, as as languages change, as you, you change with understanding and knowledge and problem solving and also even starting a journey through solving a problem. We again which is what we're doing with development we're solving a problem or a task or satisfying a need which again a need could be for solving a problem. I always look back and say, wow, I would have done that differently. Oh, wow, I can't believe I did it that way. And it may have been effective, it may work, but sometimes, as change comes, it's nice to look back and just scratch your head and say, why did I do it that way?
Speaker 3:and just scratch your head and say why did I do it that way? And in the space we're in we have clients that move between providers and when we're at a trade show, when we meet up, we're all comrades with the same type of problem. But we're also sometimes competitors and I will get other people's code and I'll get to read what they did to solve the problem. But you got to never judge another developer by the code. It could be, and I've been held hostage by clients. You have to get this done in this amount of time. Like I'm about to do something I'm going to regret and I've read an apology. I've gotten somebody else's code and there was a comment block on top. It says client required this. This is the only way I could solve this at the time. I'm sorry it's their manifesto.
Speaker 2:Yeah, yes, I've seen some of that, but you make a good point and I follow that as well as and I've learned over the years, I never criticize someone else's code because you don't know what you don't know and you don't know the situation that they're in, because we have all gone through situations where you have a requirement and that requirement changes throughout the process, even myself I say you know, okay, we'll just add this one thing, we'll add this one thing, add this one thing, all those things.
Speaker 2:Had you known about them all at the very beginning, you would have done something completely different. But you didn't have the opportunity to go back and rework it because some of the requirements may have changed. It's not necessarily in the sense of scope creep scope creep because it may have been a requirement one at one point which was completed. Then requirement two was to tack or add additional requirements to the first requirement. And you don't always have the opportunity to go back and redesign and rework everything because of time, budget, a number of reasons. So I try not to criticize. There will be a few rare cases where you can look at something and go why were you just doing that?
Speaker 3:yeah, this looks like someone's junior programmer. Yeah, someone's just warming up. The variable names are garbage. Yeah, but for the most part there's a lot of talented people in the space and you know I'll get something and I I start to know names of people I know. I know several different groups of initials, like oh, I know, I know this guy, I've seen his stuff before, his stuff is typically good, so why is this crashing? And I'll go through and go. I bet the customer changed how they do this and you start to know the people in the space and a lot of respect for a lot of really creative people out there that have solved some problems that I might've just said no.
Speaker 2:It is, and with the evolution of the language it gets a little challenging as well, because now each revision or each version of the language that comes out, you have additional functionality. So something you may have had to solve even a year ago wasn't in the language. So now you look at it and go, oh, you could have done it this way For efficiency.
Speaker 1:I think we had a conversation about that, right, brad, Like where you know, would you go back? Let's say you go back a year later and it's something that you had built last year, would you take the time to like, oh okay, I should be. Maybe I need to rewrite some of these areas to be more efficient, or do you just leave it alone?
Speaker 3:It should be a list. No more temp tables. There should be a list.
Speaker 2:Well, I would love to go back. I think it depends on where you are and what you're doing. I think if you have an application or an extension that you're publishing, you should enhance it obviously over time.
Speaker 1:Yeah, that makes sense.
Speaker 2:For the better use of your customers. Customer implementations. It's difficult. When do you do it? How do you do it? Because of the amount of time it may take, and it's not just the time being, budgetary constraints, but time for the customer themselves if they have to get involved in testing and user acceptance and all that process too, so it becomes a bigger project. That is a good question of when do you do that, why do you do that, how do you do that and should you do that? Why do you do that, how do you do that and should do you do that? Because it's also to the benefit of the customer and sometimes, if they don't understand, it's almost as if you have video cameras on your house. I'll buy a video camera today. Wait two or three years, should I replace the video cameras? Even those video cameras are working.
Speaker 1:What would I?
Speaker 2:get for it Would I get. I get better results.
Speaker 1:I'm just trying to take a step back. Someone still has to pay for it, right?
Speaker 2:Would I still get better results? Would I get better? Would I get better resolution and a higher quality video, or something like that? Somebody does still have to pay for it, but how do you equate the, the benefit to the cost, and sometimes it's not so easy. So that is a good, challenging question of should you do it and when do you?
Speaker 3:do it? And how do you do it? Um, you know, swapping out temp tables to lists, maybe you know, on a grand scale, yeah, you'll benefit, but if it's not broken, they're not going to get anything from it right now. But then there's some stuff out there that's like hey, you know, there's a lot of new features um apis, going from page-based apis to api 2.0, where they're more stable, you can do the faster read. Only there's real value in that. We need to move you from using this page as an api to a real api get off the old data.
Speaker 2:I'm thinking about all of this now and it's just really that's a good framing, because if you go back to a lot of these implementations that they have, how you can do some sort of analysis. Then again, like you said, if they don't realize the bank, the benefits and gains that they would get from it, what do you do? And or do you do it as part of another task when you touch it, as they say so, if you have to go and enhance it.
Speaker 2:It's, it's a challenge. It's a challenge and then it becomes challenging to support some of that stuff as the years go on and ultimately you may end up getting forced on some changes to to move as the application and the language which yeah, when we all get the email, this feature's going away.
Speaker 2:Time to catch up those, those, uh yeah, those wonderful emails. Well it's, at least if you can get some testing ahead of time, you can try to get in front of it. So what are some other uh cool hacking type things? Have you done with an al to push it to the limit? So you've worked on that.
Speaker 3:Uh, advent, uh the 25 did the advent of code for fun. Um, life's been really busy lately to be able to do any other really crazy stuff, but just a lot of the API things have been a lot of fun to use Business Central as the back end to do work for other APIs and other processes, just because it's easy to write code in. Just because it's easy to write code in A lot of our integrations. We just push data into BC using an API, to a temp table and then have it, since it's such an easy language to do record-based work in, do a lot of our processing over there and just having a work frame like AL is just nice. It does record-based work and if that's what you're doing, I mean I'd prefer sequel, but it's a close second well, it is because there isn't many languages I can't think of.
Speaker 2:I don't know every language. Obviously it's it's tough to know them all and they seem to come and go and even can create them, but where, like you said, it is one unique thing, where you have a language where it does handle all of the data management for the most part for you and, like you said, it's, it becomes a record based system where you can work with the records and work with the data easily as part of the language, without having to make the connection, pull back the data set and to then manage the data set that way. And then it's even, you know, with the ui putting the fields on the page. It's so simple now. You just have a field and you put it on there and it's magic. It works with the data set, the underlying data set so I do like that.
Speaker 2:I like a lot about the language. I do see it moving to me. It's becoming more and more dot net. You know, I wonder almost if you should just rip the band-aid. I understand for backwards compatibility and all that stuff over all the years, but eventually do you just, well it does. It does get transpiled into c-sharp anyway it does.
Speaker 3:It does in the end.
Speaker 3:And I and I cornered one of the uh, the developers and said why, why can't I just have the rest of mynet and it? And it actually came down to performance and stability where if you gave me all the toys, then I would use all the toys and the platform is not efficient for all of that. And having a gated set of functions and features means that I won't be doing 40-year transforms in Business Central because I won't have the tools to do it and I won't be tempted to waste the SaaS platform's processing power on something it shouldn't do and that if I really want to unlock it and have all thenet stuff, kick it out to an Azure function and pay for that and and use all the power I want, but don't use it off of their SAS platform. And and it makes sense it keeps. It keeps us gated, it keeps the mice in the maze where we're doing the things that they can anticipate, they can code efficiencies around and they can make sure we're not going to suck up all the resources by by doing something crazy.
Speaker 1:I understand that.
Speaker 2:I understand having a scaled back version of C sharp. I guess you could say or, or AL dot, yeah, or or the site. But guess you could say or or AL yeah.
Speaker 2:Or or other sites, but it does seem to be aggressive, which has made development much nicer and easier with it, because some of the tasks that you may have to do and again you can argue it goes back to what you're saying with the calendar, the. How complicated tasks would you have to do within an account? You know ERP software. I'm not saying people haven't done it.
Speaker 1:I'm not saying they're on cases to it.
Speaker 2:So before anybody starts telling me, that, oh, we can do all this complex stuff. You can do some amazing and great things, but again, the underlying nature is is business processing and business processing. If you need to communicate with other systems, you have the framework for that. So it's more of like you said, it's the, it's the record management of the data that you process within your ERP system.
Speaker 1:It's keeping you focused within the application. You're not like the full-stack developer where you have to learn all these hundreds of different languages. You're just sticking with AL. Is there any point in time you think that's going to happen, where you have to eventually learn all the other languages because you can integrate it with other things?
Speaker 3:I don't know. My team is mixed so I have two types of developers on my team. I've got the AL developer. He got a job, he's in IT. They bought this new product called Business Central and, look, you can extend it here. Here's a manual and the platform.
Speaker 3:Go to it and learned how to develop in al and al is the his, his main language, that's the that goose main language.
Speaker 3:They know al and maybe a little bit of a couple others, but they're they're al developers and they approach every problem with straight al.
Speaker 3:And then I've got other developers that know a dozen or so languages, program crazy things on the side for fun and and do all sorts of stuff and they approach things very differently and it's it's fun to team them together because the, the al developer, will come in records first and then the page layout will be exactly like every other page in business central and and the process flow is is very predictable.
Speaker 3:Based upon that way business central does its stuff, where my, my stack developers that know a bunch of different languages are like well, in c, sharp I would do this and pascal I would have gone this way, and they're looking at it from a bunch of different angles on how to process the data and their layouts come out looking more like windows apps than business central al pages. But they've made al do some weird things like yeah, I need a custom control for this. And they're just knock one out out in Java because it would look better if they did it that way. And it's neat because the unconstrained by language brings different ideas in. But then there's efficiencies and concepts and controls from the AL developer and they kind of pull each other to this really neat center of a really innovative solution to a problem, but still very AL and business central friendly.
Speaker 2:You hit something, I think, from my perspective and I just read a book called Range which talked about specialization and understanding which goes back to something with development that I've always believed in is sometimes it's understanding the concepts of what you're trying to do versus the language that you're doing it in. And if you understand the concept of what you're trying to do even more so in 2025, you can learn the language that you need or how to say it in the language. Similar to, if I went into a foreign country and I didn't know the language, I would be able to learn by being immersed in it somewhat quickly, I would understand what I was trying to say and I would be able to figure out what I was trying to say. Maybe not learn the entire language, but at least conceptually I knew logically what I was trying to say. Maybe not learn the entire language, but at least conceptually I knew logically what I was trying to say.
Speaker 2:I think it's the same case when it comes to programming languages.
Speaker 2:Again, it's another language, it's a way of speaking, in a sense, and also to your point with what they do, with coming around, and I see a lot of developers that are talented developers in another language or another platform, come into AL and try to do the same thing as you had mentioned some unique and creative ways of trying to solve problems within AL, but without understanding the business application, it creates some more issues, or they think they have to solve the problem with a little more complexity than you need to do with an AL, because AL has the structure to work within the application.
Speaker 2:So in a couple places it goes back to what I'm trying to say is I think understanding the application is extremely important, and how it works, even from the user interface, is what you had spoken about. So that way, from the experience point of view and even the flow point of view, you can make sure that you develop within there and then also understand what you're trying to do, versus copy and paste a bunch of code that you see in another function and try to get it to work without really understanding why you're doing what you're doing.
Speaker 3:Vime coding To me the language comes easy.
Speaker 2:It's what we used to see a lot of back early on was a lot of copying paste from some of the the major code units, and you could actually see where somebody maybe took pieces of individual sets of code and put them together and they got, they did work to give them the result. But if you analyzed each thing of what the each line of code or what the code was doing, sometimes they were counter, uh, counteracting each other, and it's almost like set a flag, unset the flag, set the flag, unset the flag, and they, they could have reduced it.
Speaker 3:So could have been simpler.
Speaker 2:I do see that where a lot of individuals come in without knowing the application, it becomes a little more challenging a little challenging, and it's.
Speaker 3:I think it comes down to one of the things I chat with my low-code, no-code friends about is, I mean, the language learning. Al is a barrier. It is more complicated than Power Automate or any of the other workflow tools, but the challenge I don't think and maybe it's because I'm old and gray-beard at this point the challenge is not the language, it's learning how to solve a problem in the environment you're working. How do you? You know the client says they want this, how do you break their expectations down into things and steps and processes that you can do? And I think that's the hardest part of any programming project is not the language and again, that might be because I'm old, I'll accept that, but it's a lot of. It is teaching people how to look at a problem and go okay, what's the smallest unit in this problem that we can solve right now? What's the first thing? Well, the first thing is we're going to need to, and they blurt out the whole problem. It's like no, that's the whole thing. Again, how about? What does the data look like? And break down the data? Okay, now, what's the flow of the data? How does it get in and get out and work it piece by piece.
Speaker 3:Taking a complex problem and turning it into those little pieces that you can code is, I think, the real skill. That is the toughest part to learn for any language. And once you know how to think like a programming language, then new languages is is not as hard. Because, all right, I, I know I need to break down to this piece. How do I do it in al? How do I do it in lua? How do you do it in c sharp? That's syntax, but you know you need to find how to get to this, this piece.
Speaker 3:And uh, a friend of mine was was learning lua and asked me to help him learn it. I'm like, okay, well, what we're gonna do is we broke it all down in english and we hopped into uh, copilot and asked it how to do each of the little steps in lua and we were able to write the program in like two hours. Like I don't, I don't know lua, but I knew how to break down software and I know how to ask the questions and and off we went and it was a. It was a whole lot of fun learning a new language by copilot and I. I can see how that's going to help a lot of people, but copilot doesn't know how to break the problem down yet, and I think that's the part that people are most challenged with.
Speaker 2:You hit it right there. It was similar to what I was trying to say is it's not the language, because you can figure out. It's understanding the framework of what you have to work with and then being able to break down and your point of problem solving now that is where the most value is for a problem is how can you analyze the problem, break that problem down and come up with the solutions.
Speaker 1:And you're absolutely correct co-pilot works best with small, bite-sized chunks so it doesn't work so let me ask you this then For people that are coming into AL development that may have a different background on different programming language, yes, it should be easy for them to pick up, you know, understanding the basic of the syntax of a programming language. But what happens for those people that are coming maybe a full-stack developer that understands, you know, they have to build the backend framework, frontend framework, all this stuff coming into AL, it's not the language that they're not understanding, but the limitation of, like, the other tools that they can use. I think that's where the challenge is. You know, and I had spoken to a full stack developer that uses, you know, react and Ruby and all the other languages out there, the modern languages, and they had an opportunity to look at AL and they're like, okay, what else can I do with it? And then, of course, they that's where they, you know they get stuck because they're so used to other tools in their tool belt to build something.
Speaker 1:In this case, you're kind of in the confines of what you have on your tool set and that's it.
Speaker 3:Yeah, it's going from free range. I can do anything in this language, not that I should. You can do a whole lot in React and then you go over to AL. You're writing accounting software. You don't need to animate anything. Put that down. There are things you don't need to animate anything. Put that down. There are things you don't need to do here and the language is not designed to let you do those things here. And it's back to. I would talk about giving you free range of NET. It's not going to give you the resources and the computational power to do it, and we're also going to sell it at a pretty decent price per license because we're not going to give you the ability to do things that are off brand. You are doing accounting here and that is all.
Speaker 1:So in that case, if you are someone coming in and again we're always looking for new talent right Coming into the business central development and some of those may bleed from other modern languages. So is it fair to say if they were to build a solution, they should also build it with a mindset that it can be consumed by other you know tools or consumed by other, whatever integration language that you're going to use, like for example, you may build a solution where a power automate can consume right.
Speaker 3:Is that?
Speaker 1:something that you should consider as a person, that's building solution.
Speaker 3:When I'm building stuff I like to think about okay, I'm giving them some tables, I'm giving them some pages, Because that's what's in scope right now A couple tables, a couple pages. But you know, it's a few minutes to take these key events that happen and turn them into business events, and that lets us fire easily into Power Automate. Maybe I'll throw I mean, it's just me working here, but I'll throw integration events in here so that later we can extend and grab on. It's nice to think about future, you and the future use cases, especially when things like business events, which are just fancy, fancy webhooks, are almost free to add in.
Speaker 3:When this process finishes, just fire that webhook and then later when the customer says, oh, I really wish I could get an email when this finished, Okay, Go to Power Automate, grab this event, send yourself an email and they're like oh, wow, you really thought that through. Yeah, I really thought that through and it gives you that extra bonus thing. And then when I find them from others, I'm like ah, that person was thinking about the future too. And it's great because we have those abilities and knowing that the language has limits and that I may need to send this out to another package, another product, another tool, set to finish or to do more work. Knowing you have those limitations and coding in the ins and outs for it makes everyone's life better.
Speaker 3:But sometimes you just can't because a lot of these projects that we do, we give them a quote but the budget was set before we showed up. They know how much they're willing to spend on the project and really we're giving them a quote and then we're going to argue it down to what they were going to spend anyways and make compromises and sometimes that extensibility is the first thing off the table. But when I get the chance, it's great to be able to do and then get those benefits later. When that extra scope does come up a year later, when they're ready to add in automations and things You've already put the hooks in, that's great, that's a lot of fun and you've prepped it.
Speaker 2:To go to a different language there because, with the application constantly changing and evolving, to have that flexibility, as you had mentioned, to put some of those events in there or to even code it to the smallest possible function and then tack those functions and build them blocks together is their savings in the long run, and it doesn't take much to get into that habit.
Speaker 2:As you had said at first. It may take some time to think about it and to do it, but where I got into the habit, that was testing Once you really start getting into automated testing. It teaches you or forces you to work with the lowest common denominator of functions and then you just stack those together and building blocks, even if you have to do the repetition as you go through each to be able to have that expansion and to provide the value.
Speaker 2:It's funny that you say the budget. They do have a budget. I love those conversations. There's a budget of what they want to spend, which means what's the value? Right? I always look at it as the value. What's the value to them for what they're looking for, them being the customer? And then when you have to give a quote for it, I almost want to say, when someone wants to argue it down, it's almost again.
Speaker 2:If somebody I would say in every episode is like building a house or putting a deck on, if you have to make a compromise, I told you the deck was $2,000. If it was $1,000, I would have told you it was a thousand dollars, right? So if you want to take a thousand dollars worth of value off, okay. Well, now, instead of using trex vinyl, for example, if it's trex vinyl, trex composite, you now have to use wood. The wood will rot. It can be a cheaper price, but you'll have to replace it long. You know you have to replace it sooner than you would have to if you had the trex. And that's sometimes the conversation that you have and it does come down to everybody has a value for something, right?
Speaker 2:And all of us do it. If I go buy food, what's the value of the food I buy to me? I'll pay the value that I think it is, and it's almost like a different conversation when you start looking at the value of it and then understanding the changes that you have to make. And it's not, it's not like a negotiation, where you know you come in high, you know with the intention of, okay, well, we can really get it for this, but we're going to shoot for the stars. It's always difficult conversations to have.
Speaker 1:Yeah, and I think and you mentioned about like your future self maybe maybe having that conversation of like if it's a PTE or a specific problem you're trying to solve for the client, it's a one-off thing.
Speaker 1:You estimate it and then you build it.
Speaker 1:Maybe you'd add some business events.
Speaker 1:But maybe, from the flip side of that, if you're building an ISV application or something like that, then perhaps consider that so that your solution can be extendable beyond the confines of Business Central.
Speaker 1:In this case, give some love to the low-code, no-code people there in the world where they can then interact with your application and I don't seen that as a practice out there, but it would be easier for the benefit for your clients that are using your app, but also benefit for somebody in there where they can consume it and do something beyond your application. I think your application becomes very useful in that sense and just focusing on maybe adding the features that pertains to the business, but the consumption of other areas would be helpful, because there's been times now where we have a client that says, hey, we want to utilize part automate, we wanted to see or trigger based upon a change on this table. Well, the list you have is very limited and it may be a table that is a custom table or whatever. You have to build that right. But it'd be really nice for maybe it's my wish list for all the ISVs out there to consider those for when you're building your application.
Speaker 3:When I talk to ISVs, I usually corner them and say okay, look, here's the deal. If you tell me that your product does 100% of everything my customers want, there's either one of two things are true. One, you're bloated and way too expensive, or two, you're lying to me. One or the other, because there's no way you can do 100% of what my clients want. They're diverse, they've got odd expectations. They span so many industries. You can't make a product that does everything they want.
Speaker 3:So give me a product that does 80 of what they want and a lot of web hooks. Yeah, give me business events, give me hooks, I will do the%. That's what I'm good at. I don't want to write a warehousing product. I don't want to have to maintain an entire warehousing product, but I'll write the 20% that turns your warehousing product into their warehousing product and get the most benefit out of it. And then you don't have to deal with all of the weirdness. Right, the best 80% you can. And then give me the 20. And and that's where people like us all shine yeah, like, this works almost like I want it to. I got your fam. What do you want it to do? And if they've got all the hooks in there, then we set it up and we make it do what they want and the customer's really happy.
Speaker 1:We're only dealing with this little 20 that we tweaked and and the and the isvs got the other 80 and, and those types of relationships work great yeah, it's, it's a series of isvs that do that yeah, it's spot on, because there's been times where, like this function doesn't, it doesn't exist in this ISV, and then, whether you have an opportunity to extend that or if you don't, you send an email to the ISV and say, hey, maybe add this on your future release. But if you create some other events where they can consume for example, even as simple as notification that Power Automate can consume, that you don't need a developer, that a power automate can consume, that you don't need a developer A client can go ahead and just consume it or extend it using power automate for their whatever use they need.
Speaker 1:It's not something that you should, maybe don't care about, but giving that power back to the end user it's powerful, Makes your product much easier to handle.
Speaker 3:Yeah, and I got ISVs that I'll send an email to hey when I get to right here I need an event and sometimes they'll send back going. Oh yeah, that's the on before. Blah, blah, blah. Great, thank you, I'm going to go use that. Other ones, it goes okay. Next release we're doing a release in a week. Watch for the event. Good, thank you. And be able to hook in and do the things I want to do. And that type of the ISV relationship in this space is great, because they're typically really open to listening to us down here on the ground saying I don't want you to add this to the product, that would be crazy, but I need it. So can I have a hook or an event or something to do this? And they're pretty receptive about that.
Speaker 2:They are. A lot of them have been very willing to help again.
Speaker 1:Some less.
Speaker 2:Thankfully I haven't had to run into too many challenging ones. I think everybody wants to be. You know it's the benefit of everybody. Rising tides raise all ships. I want to jump for a little bit. So you worked with GP before.
Speaker 3:Yes.
Speaker 2:Can you develop with GP or in GP?
Speaker 3:GP has its own language called DEX, and it's my least favorite language. So as a company we did virtually no decks. We farmed it all out. Uh, at one point gp tried to do a dot net wrapper to let me write uh, gp forms in dot net and they looked almost like gp and that that didn't go anywhere. Uh, most of our work was uh fiddling with stored procedures and sql triggers to to do more math. Um, there was a couple tools called extender that let you add fields. Um, it was very, I want to say, dirty, because a lot of times you're just in the stored procedures or watching for insert events on sql tables to do automations.
Speaker 3:It was challenging and we still have lots of clients on GP. The migration is slow, so I still get lots of calls to work on it and it's challenging when everything you do is outside the product. So you're attaching on SQL, you're using extenders and things, but you're not a first class extension unless you're in Dex. And even when you're in Dex, loading in these dictionaries they're called, they kind of just bolt onto the side just barely. And then moving over to something where BC, where all extensions are treated equally, you have parity across everybody. It's totally different. I can do anything the big boys do. In fact, we have the big boys code, so if they're doing it, we can look at how they did it, and it's very, very different and very constraining on the GP side.
Speaker 2:I've talked with GP users. I haven't really talked to anybody about the GP development or extension to get a full understanding of how you make enhancements to it, so it seems even from the transition. So not only would you get a product that's a full if you were to move from GP to Business Central, you also have the ability of the flexibility again, where you have an application that would have 80% of what your business needs and that last 20% which may give you some uniqueness or specialty for your individual, specific business. It's much easier to get there and maintain and move forward than it sounds like it is within GP.
Speaker 3:Yeah, there's a point in the conversation when we're moving people over and we're starting to do their data migration, it's like, oh, you used these two user-defined fields for these values, what are they for and where do you want them in BC? And they're like, oh well, this is the customer remote account number or whatever. Okay, so you need a remote account number. What else do you need? Well, we have another Excel sheet where we keep track of what system it is. Do you want me to put remote access system on the customer record? And their heads explode Because, like, wait, you can just add that field.
Speaker 3:Yeah, do you have other data about this customer that you're keeping scattered, as my grandmother would say, from hell to breakfast? Do you have other data about this customer that you're keeping scattered, as my grandmother would say, from hell to breakfast? Do you have scattered data that you would like here? And there's Excel sheets that come out of nowhere of. Here's all this other data we keep about our accounting system, but it doesn't fit inside GP, so it's over here in this Excel sheet. It's like, oh well, I'll just add those fields and we'll just import that data and automatically we transform their business just by getting rid of an Excel sheet of poorly managed data and putting it right inside those types of constraints. When they go away, they really change how a business works. It's a lot of fun.
Speaker 1:What's the biggest constraint? I know there's been apprehension of moving from GP to BC. What is the typical one? One that I've heard is typically a customization that's unique, and trying to replicate that in Business Central may not be viable or maybe too expensive. I don't know. I'm just curious from your perspective. I've never worked in GP, either, in passing, but never done anything beyond that.
Speaker 3:Well, I mean, gp is 40 years old and it does lots of things in a very GP way. And moving those processes into the BC world, I mean GP is segment accounting and BC is dimension accounting. There are different ways to think about and work your data and if your business has been influenced by the way GP does things, then you have to change the way you do business because BC is a different way of doing things and it's. Most people don't think their accounting package has dictated how they run their business, but it does. If it is more work for you to put data in a certain way, then you will find a way to put it in that's easier and your business will constrain itself to that methodology.
Speaker 3:And then, being 40 years old, there's lots of-ons to gp that the companies don't exist anymore. I can't. I can't get that customization. It's not there. And it was like there's some really big ones that haven't moved to bc, probably are never going to move to bc and um that's. And moving those specific clients over is very difficult because there are tools that just don't exist.
Speaker 1:Yeah, and they would have to be rewritten, or hopefully an ISV exists.
Speaker 3:At some great expense. Yeah, and it would be expensive.
Speaker 1:And the customer pays for that right. It's not like someone has a deep pocket that can recreate that solution, and you do hope that there's a ISV or an add-on on the app source that would partly replicate that. But there's always going to be a little bit of effort to somehow get that to work or maybe even change a business process because of that. So I think that's where a lot of challenges.
Speaker 3:And that goes for any system. When we pull people off of QuickBooks and they have to follow a more strict rule set Business Central rules are more strict than QuickBook rules, a lot of it dealing with the fact that business central is multinational. You can do things in QuickBooks that's not legal in Europe and so there are more rules. Pulling someone from NetSuite or any of the other great accounting packages, there's nothing wrong with them Intact is cool but they all have rules, they all have limitations and they all dictate a bit of how you do business by those limitations and those features. I do it this way because NetSuite does this really well and it streamlined my business by doing this. If BC does that a different way, you're going to have a hard time switching and I'm not going to rewrite BC to make it into NetSuite. That's just not how we do.
Speaker 1:Yeah, there's so many of those right where they're coming from another ERP, going to Business Central, and it's like I want it to work just like that one, just like this.
Speaker 3:And a lot of times those folks are coming over by acquisition. They got bought parent company's on BC. You're getting on BC. They don't want to do it, so they'll find a reason not to.
Speaker 2:And that sometimes is a risk during implementation is, if somebody's saying that they can't do something or they need something, really validate why they need to do it that particular way. In some cases, it could be from a self-imposed limitation, or a limitation that was within the previous system or a previous process, or even the size of the warehouse they were in at one particular time, and they just came up with a process that you had to follow with. It's challenging, it's challenging, uh, it's. It's challenging it's challenging it's.
Speaker 2:It's. We can go all over the place with this, but to think about the development with, with an al, from the from the al development point of view, do you ever take a look at when to develop, when to extend versus when to use the base functionality?
Speaker 3:that's always a challenge. I'm a developer, I'm paid the right code. So a lot of times when I turn to my client go, you know what? You should just download this extension. It's free, you should just do that one. It breaks my heart a little because I would like to write the cool code. That's kind of what I'm paid to do, but at the same time it's the customer's best interest and that's a part of being the gray beard is, when I was younger I would write code for everything. And now you know you said get older and you're like I don't want to maintain code for everything. That's a that's. That's a lot of extra work and clients hate paying for you fixing things that broke that they didn't break if it doesn't bring value.
Speaker 3:Um, the the big wave updates when something changes and I have to do a fix. They're not getting any new features from me. But I have to go fix something that microsoft broke. They hate that. And the the more code I put out there, the higher tech debt there is.
Speaker 3:So I want to extend when it brings the most value to the client. I want to use base functionality when I can and use off-the-shelf things that I can buy and leave that tech debt with somebody else to manage when it's applicable. And again it's back to that 20%. I would like to be able to use the core and then pick up modules from reputable ISVs for 80% of the stuff the client wants to fill that gap. And then I'm only developing 20% and that comes down to tech debt. Like insight works, they've got a huge package. That's a lot of tech debt, but it's one deployment and when it breaks they fix one thing that impacts a thousand clients.
Speaker 3:If microsoft breaks something and it's in all of my extensions I got to go fix it on every single client. They recently renamed a function and if you were copying reports, you know back in BC, 15, 16, there was no report extension. So if you need to change a report, you copy the report, you'd paste it and you change the number and then you'd edit the report. Dark, dark days, those were um. So all the reports that were modified that way had a uh a function in it that microsoft decided that it should be the full name, not not this crazy short name, and I had to go find it. It was in 26 of my clients that we copied that report for.
Speaker 2:You're talking about the language.
Speaker 3:Yeah, yes, language is not allowed. I had to go find and change it to CU language in everybody.
Speaker 2:Yeah, language was one of those ones that. That was just a recent update that they got anybody, like you said it would copy the reports over. I saw that and uh, sequence template template sequence.
Speaker 3:Template sequence. It was sqnc, now it's sequence like the full word.
Speaker 2:That bit me in a couple yeah no, it's interesting to see some of, uh, some of how this evolves and, like you said, you made some good points. You know the tech, that where you can manage it in one location, in one place, and it also provides a very better value for the implementation as well. Like you said, you don't have all these little offshoots off, uh, all these little crazy extensions yeah, to do some certain things my team would rather solve the weird problems.
Speaker 3:They don't want to. You know, the easy stuff that there's something I can get off the shelf really well doesn't help the client. It doesn't excite the team. If you've got a team that's excited by sitting with the client talking through a challenging problem and finding a neat solution, that's a great team to work with. And having them do weird little things where there's already packages to solve them, that that's no fun. You want to. We didn't get in this, this development career, to to be bored. We wanted to play with the latest technology, solve challenging problems. We want to. It's kind of fun. We're broken people that that's what we do. And uh, being able to have the, uh, the, the, the opportunities to do the neat projects that that comes from staying out of the things that have already been solved yes, thank you.
Speaker 2:Well, that's okay, but i'm'm with you on it's. It's always. What I say is it's. It's. When everyone says they try to do this cool thing and they don't want to hold onto it to where they're maintaining it forever. For me, I've always had the mindset I'll teach someone to do it because then I can go off and do the cool things and it's like you said right there don't waste your time doing the things that have already been solved or there's a way to solve it easily. Worry about focus your time on doing the things that are challenging and not challenging, because you're only doing the things that are challenging, but value and spend your time where it's needed and if something hasn't been solved, if you have something complicated to work on, work on that versus, like you said, creating entire warehouse implementation software package when there's some that are already available that you can extend, which is nice yeah yeah, and I don't know if we're broken I don't know, I'm gonna, is everybody else broken?
Speaker 3:I I got. I have a stack of board games behind me. I've got weird electronic things happening back there. That crazy orb, right, right there is actually changing colors and patterns based upon the online status of my team members. It's connected into teams and it just the patterns on the ball change based upon their uh, their availability.
Speaker 2:That's very cool it just sits there why do you do that?
Speaker 3:uh, that's the kind of broken I am.
Speaker 2:Okay, yeah, I didn't know if you were doing it just to see if somebody was online or if they were offline, or you just wanted to tinker.
Speaker 3:It started as a Christmas project. I made a wreath that had all the lights on it were different team members on the wreath, because what is the holidays without a little bit light? Stalking of your coworkers? And it was behind me and and changing colors and I spent a lot of time doing it.
Speaker 2:So I I have that. See, that's the stuff I want to talk with you about.
Speaker 1:I want to do that cool stuff yeah, it's like all these side projects, it's not just, it's not just business central right right, no, that's, it's all side projects.
Speaker 3:That's um, there are a bunch of lights called a neopixel and there's a um, a board called an esp32. There's a little microcontroller that's hooked on my wi-fi and I've got a companion app on my computer that gets everyone's team status and sends it over to it the companion.
Speaker 2:Did you write the companion app? Yep, okay, actually did you do this with, like that raspberry pi? I was reading but I say you can't. I can only do so many things, but I would like to have some of those cool things. Is that board similar to, like those raspberry pies?
Speaker 3:the pie is a whole computer. This is less so. It runs a block of code. You can write code and it runs that code. It doesn't have an operating system like you would with a desktop, and this actually came out of covid. Um, the kids were home from school. I've got meetings so I had hung two lanterns outside because my wife works from home too, and the lanterns were hooked to our team status and if we're on calls they return red. That way when the kids came terracing down the stairs wanting snack or something, they'd see two red lights outside and stop and go back upstairs.
Speaker 2:See, that's a practical use.
Speaker 3:I like that, and that way you don't have to worry about turning it on and turning it off so it's kind of like the on-air light and they were outside our offices so that the kids would know what our status is. That's something.
Speaker 2:I want to do.
Speaker 3:It's on my GitHub if you're looking for it. The whole project is there.
Speaker 2:Which? The Teams one or the light, the Team light or the? I'm on a call light, or are they all on there?
Speaker 3:Well, the on-the-call, it's just the teams like watching one channel where that guy is, the teams watching everybody's channel. So it's just a matter of who, who you want to light. Whose status goes to which light. So you put your status being all of them. So I could, I can, set it to my status, which would turn it all red now. So it went all red on the background there. I can't see it. Yeah, it's red, it's kind of blown out. Or I could set it to Dottie's status. Well, she's free Now it's all green, that is fascinating Brad, maybe I'll do that for you I like this.
Speaker 2:Are you available? I could just look back I like that.
Speaker 3:No, I see that that's. And now it's going back to the work pattern that is hilarious.
Speaker 1:That is some of the cool side projects. Right to be able to do those see.
Speaker 2:Those side projects are cool. That that is like I said. But there's only so many things you can do with technology and everything going around it's. I find it's hard for me to want to read. Sometimes I feel like I have to go outside you know, and then, and uh, it's just a touch grass for a minute yeah
Speaker 3:you don't have grass down there, I have grass oh, you have grass and then I do things with 3D printers and lasers. Have you ever been to a makerspace?
Speaker 1:yes, I have been to a makerspace. My son is on makerspace and that's fun to see so yeah, brad, it's like a gym for nerds.
Speaker 3:Instead of having weights and swimming pools, it's ours has got a wood shop, a metal shop. Uh. 3d printers, laser cutter engravers it's got all that stuff?
Speaker 3:where is that? You don't have to get my mine's a mile up the street, but they're, if you, if you look for maker spaces near me, also called hacker spaces um, they're different ones. They're they're usually community-based. Um. There's another one in next town over. They're more electronics and, uh, auto body, they have a, they have they vehicle lifts. Uh, there's one north of us, near the theater district in in manchester, um called um, let's see, make it in nashua manchester makerspace. They do a lot of theater, a lot of props, a lot of a lot of work like that, because they're near a theater, so their space is very theatrical houses in a school, so it's super educational, focused it's. It's a lot of fun and all these places let you get in on tools that my wife won't let me buy that's, I heard of it.
Speaker 2:That's why I asked, because I've heard of one around there and I remember talking with them when they were trying to put it together, because they were looking for funding to help because they wanted to go with the educational portion of it, which I agreed with, because any place where you had that's what I was asking about, because they had a memory of that with seymour and someone was looking for funding because then they would allow local you know, local school-age children to come use the services so that they could learn different things. So that's why I was asking, I was just wondering if it was the same one yes, it was make it.
Speaker 3:Labs in in Nashua has done some really cool stuff.
Speaker 2:They're a fantastic group. Yeah, that's the one that I was referencing.
Speaker 1:Makerspace is amazing, especially for young. I know my son is doing he was doing Lego robotics, and so they get a lot of funding from local tech companies like STEM, things like that. So you know you are welcome to do, even as an adult. So you know you are welcome to do even as an adult. So you know, get to learn all of that stuff. So it's great to see them build something and then have a Lego robot solve problems with some of the obstacles that it has to go through, which is very, very fascinating. And, of course, it gets them started on. You know programming, language and you know developing those things. Pretty cool.
Speaker 3:My son was learning how to mig weld. He's got a mig gun that sparks flying everywhere and I hear him giggling under the mask as he's melting metal and having a blast it's great.
Speaker 2:Had I known marcel was so close and into all this stuff, I wouldn't have moved. Yeah you're welcome back anytime, I'll be back, don't you worry, I'll be back. Uh, yeah't you worry, I'll be back.
Speaker 3:I missed the get-together last time because it just kept moving around and I wasn't able to. No, I understand.
Speaker 2:We'll definitely get it during the next trip. But no, I have to be back with some more permanence. New Hampshire will always have my heart.
Speaker 3:If you're up on a Thursday. We have Makerspace open house every thursday from 6 30 to 9. Come on by and we'll uh, we'll cut some stuff with a laser that's so cool I want to make a team thing, okay, or something I want to make something.
Speaker 2:I don't know. I don't know if I wanted to get into that, to get into the raspberry pi. I was trying to think of like some cool practical uses or something I could do. Maybe I'll have to like tie it to business central somehow.
Speaker 3:I don't know there's a thing called a pie hole that you can make it's. It's a one-day project. You can order your pie online and what it does is you plug it into your network and you set it as your dns, and when web pages pop up that have ads, it sends the ads into a black hole so they don't show up on your screen, and it sits back in my network cabinet, plugged into the network, and all my computers in the house are ad-blocked through the pie hole.
Speaker 3:It's a one-day project Google it Pie hole.
Speaker 2:P-I-H-O-L-E. I'm going to look at it. Pie hole I thought your pie hole was something like that. I always heard of piehole being a mouth.
Speaker 3:Yeah, you're putting your piehole. No, it drops all of the ads. It does a great job filtering. It doesn't get 100% but for no load on my computers it does a great job of toning down all the ads online.
Speaker 2:I will have to look that up and see what I can do with that and I'll definitely next time I'm in the area if it fits on the Thursday evening have to come to this maker.
Speaker 3:And the weather's nice.
Speaker 2:Well, maybe you have to be. Is it better when the weather's nice or better when it's cold and miserable?
Speaker 3:It's in a school and as such there is no air conditioning in the summer because the school is not technically open, so it gets hot in there.
Speaker 2:So yeah, cooler days are better. Okay, that's what I started to think about the time of the year, because I know how it gets in those. I'll definitely have to go through that, and then we'll also have another get together the next time in the area, and we'll try to not do it on a Thursday. It just worked out. You know how the schedule is when you try to get several people together. Well, marcel, thank you for taking the time to speak with us today. I look forward to speaking more with you and I have to check out that Advent thing.
Speaker 2:I know we spoke with that some months ago as well because unfortunately, you know, sometimes the year gets a little bit busier. But now it does. Things are freeing up where I'm going to have a little extra time to do some fun things, so we do appreciate you taking time to speak with us.
Speaker 3:Thank you for having me on. It was a blast.
Speaker 2:It's always. We couldn't do this without an individual such as yourself. If anyone would like to learn more about Makerspaces, about some of the cool teams that you can do AL Development, gp, business Central, all the cool nerdy things you do, or even rocket science what the cool nerdy things you do, or even rocket science.
Speaker 3:What's the best way to get in contact with you? Uh, you can find me on linkedin it's marcel chabot or you can find my blog at aardvarklabsblog and, uh, I post educational content, makerspace stuff, there, uh, almost weekly. Um, I have some bigger projects in mind that will probably slow that pace down, so stay tuned to see what I'm, uh what I'll be working on there.
Speaker 2:And next time we'll have to get get into how the odd rock labs name came, because when I saw that with you months ago I was trying to figure out the relationship. Who comes up with an odd park? So?
Speaker 1:there has to be something you got to make it to the top of the list, man Hard bark.
Speaker 3:That's actually. It's aardvark, that's actually it. When I was uh, when I, when I used to play uh games on the local local, the lands, local area network gaming days, um, I was never sorted first by a score, but first alphabetically. Yeah, there you go, aardvark is what I put on and it just. You know, 30 years later, I like to throw aardvarks and things Still on the top of the list. Still top alphabetically.
Speaker 2:Thank you again, sir, for speaking with us. We appreciate it. I'll talk to you soon.
Speaker 1:Take care, sir, Talk to you later Ciao ciao, thanks Bye.
Speaker 2:Thank you, chris, for your time for another episode of In the Dynamics Corner Chair, and thank you to our guests for participating.
Speaker 1:Thank you, brad, for your time. It is a wonderful episode of Dynamics Corner chair. I would also like to thank our guests for joining us. Thank you for all of our listeners tuning in as well. You can find Brad at developerlifecom that is D-V-L-P-R-L-I-F-E dot com, that is D-V-L-P-R-L-I-F-E dot com, and you can interact with them via Twitter D-V-L-P-R-L-I-F-E. You can also find me at Mattalinoio, m-a-t-a-l-i-n-o dot I-O, and my Twitter handle is Mattalino16. And you can see those links down below in the show notes. Again, thank you everyone. Thank you and take care.
