The latest articles on DEV Community by Eric (@eromanowski). https://dev.to/eromanowski https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F204251%2F2f62d2f7-3d91-4871-9470-3ea2ef815f05.png https://dev.to/eromanowski en Eric Fri, 08 Nov 2019 08:30:16 +0000 https://dev.to/eromanowski/what-is-technical-debt-and-why-does-it-cost-85-billion-a-year-how-can-ci-cd-help-reduce-it-8kl https://dev.to/eromanowski/what-is-technical-debt-and-why-does-it-cost-85-billion-a-year-how-can-ci-cd-help-reduce-it-8kl <h1> TLDR </h1> <p><em>Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.</em> <a href="https://en.wikipedia.org/wiki/Technical_debt">https://en.wikipedia.org/wiki/Technical_debt</a></p> <p>Technical debt is difficult to deal with. It is costly and can hide in all facets of an organization. Having a plan to identify, log, prioritize, detect and account for tech debt is crucial to the smooth operation of the company and employee morale.</p> <p>Take your time, do it right. You may be able to go back and refactor some of the code, but you will never be able to refactor the underlying patterns. Once it gets gets to pattern changes, rewrite often occurs. Businesses don't like the word rewrite. While rewrite has a negative connotation, it often means that lessons have been learned and we have found better ways to implement business requirements that will not only benefit the business, but developer productivity and morale as well.</p> <h1> What does Technical Debt mean to me? </h1> <p>Tech debt is the sum of all inefficiencies caused by past, present, and future decisions across the entire company. It affects both the technical and business side of the organization. It is always in a state of creation and/or destruction. Once it shows up, there will always be an effort needed to remove it.</p> <h1> How much does it cost? </h1> <p>It costs $85,000,000,000 a year. </p> <ul> <li><a href="https://www.pullrequest.com/blog/cost-of-bad-code/">https://www.pullrequest.com/blog/cost-of-bad-code/</a></li> <li><a href="https://www.cnbc.com/2018/09/06/companies-worry-more-about-access-to-software-developers-than-capital.html">https://www.cnbc.com/2018/09/06/companies-worry-more-about-access-to-software-developers-than-capital.html</a></li> </ul> <h1> Ideas on reducing tech debt </h1> <p>A plan needs to be implemented to eradicate it in your system. If an implementation/system is so poor that users lose trust, it may be worth considering an exit strategy on that software and looking into alternative solutions.</p> <p>The decision to prioritize tech debt in the system should be based on the impact it is having on the organization.</p> <h1> What questions can you ask to uncover tech debt? </h1> <h2> Business processes </h2> <ul> <li>Do business users trust their system(s)?</li> <li>Are there any manual steps necessary to complete a business process?</li> <li>Do you know the specifics of data leaving or entering your applications?</li> </ul> <h2> Infrastructure </h2> <ul> <li>How quickly can environments bet stood up and torn down?</li> <li>How easy is it to manage your infrastructure? </li> <li>How is your logging?</li> <li>How is your monitoring?</li> <li>Do you have a disaster recovery plan? If so, how long would it take to get back to an operational state in the occurrence of a disaster?</li> </ul> <h2> Build/Release pipelines </h2> <ul> <li>How long does it take to get code from development to production?</li> <li>Are there any manual steps in the deployment process?</li> </ul> <h2> Code </h2> <ul> <li>Do software architects have enough control over their business unit's systems to enforce standards and best practices across them?</li> <li>Are best practices and standards being followed across the orgization?</li> <li>Do you have 100% unit test coverage?</li> <li>Do you have integration test coverage on critical parts of the system?</li> </ul> <h1> How do you estimate technical debt? </h1> <p>For estimating developer time, if you are following agile-ish pratices, during retrospective meetings, ask, if the system(s) met all expectations and were running optimally, how much time could have been saved? Log those estimates over time and extrapolate how much that is costing the organization.</p> <h1> What is CI/CD? </h1> <p>CI/CD is an interpreted and generic term that ultimately means how fast can you detect bad code, stabilize it, and safely/reliably deploy it to production.</p> <p>Areas of Interest:</p> <ul> <li>Pull Requests <ul> <li>Code review is crucial to delivering high quality software.</li> </ul> </li> <li>100% unit test coverage <ul> <li>With the world of libraries and packages, standards may not be enforced. Popular libraries will typically have unit test coverage, but it is always a good idea to do a technical audit on any new and/or existing libraries you are referencing to make sure it meets standards. It also would be a good idea to run a coverage tool on the libraries crucial to your business. (DotCover, WallabyJS are tools I have used)</li> </ul> </li> <li>Integration test coverage <ul> <li>Coverage on critical parts of the system should be a requirement. Between the unit test coverage and critical path integration test coverage, developers can merge code to master with a high level of confidence.</li> </ul> </li> <li>Pipelines are built to generate builds, run tests, and release builds. The complexity of these pipelines will vary significantly by the type of resource. The time it takes to build these pipelines must be accounted for in estimates.</li> <li>Feature toggles are implemented to deploy chunks of a system in an iterative fashion. Feature toggles are tracked and can be contextual to the user. </li> <li>Strict data contracts must be enforced on critical parts of the system.</li> <li>GitFlow <ul> <li><a href="https://datasift.github.io/gitflow/IntroducingGitFlow.html">https://datasift.github.io/gitflow/IntroducingGitFlow.html</a></li> <li><a href="https://www.pullrequest.com/blog/3-ways-code-review-makes-your-dev-team-better/">https://www.pullrequest.com/blog/3-ways-code-review-makes-your-dev-team-better/</a></li> </ul> </li> <li>Monitoring <ul> <li>This is critical to detecting issues across the entire system. Azure has a tool called Smart Detection that will detect a number of anomalies and send out email notifications. For example, Azure will track dependency failures over time and alert when failure rates go above an abnormal threshold. </li> </ul> </li> </ul> <h1> Conclusion </h1> <p>Software is hard. This was a lot of topics to cover. I'm sure I missed things, so feel free to suggest any additions to this. </p> Eric Fri, 08 Nov 2019 07:54:14 +0000 https://dev.to/eromanowski/future-of-web-dev-38f6 https://dev.to/eromanowski/future-of-web-dev-38f6 <p>Will Blazor take over?</p> <ul> <li><a href="https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor">https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor</a></li> </ul> webdev Eric Fri, 30 Aug 2019 08:56:35 +0000 https://dev.to/eromanowski/lessons-learned-moving-to-the-azure-cloud-1fcj https://dev.to/eromanowski/lessons-learned-moving-to-the-azure-cloud-1fcj <h1> TLDR </h1> <p>Going to the cloud has been an interesting experience. Spend some time up front to organize your resources by resource group and subscription. Deploying your resources to your production environment can be tricky. Spend some time looking at the Azure Resource Manager REST API. Be careful with the Powershell Az Module. We got burned by it.</p> <h1> What are we leveraging in Azure? </h1> <ul> <li>API Management</li> <li>Logic Apps</li> <li>Data Factory w/ SSIS Runtime</li> <li>Application Insights</li> <li>Integration Accounts</li> <li>Functions</li> <li>App Services</li> <li>Sql Database</li> <li>Storage Accounts</li> <li>Service Bus</li> </ul> <h1> How are we organizing our cloud resources </h1> <ul> <li>By subscription <ul> <li>Be mindful of the subscription service limit, quotas, and constraints.</li> <li>We separated our development and production environments by subscription which allowed us to limit access to production resources as well as have a clear division for our billing. </li> </ul> </li> <li>By Resource group <ul> <li>Pay close attention to the location you put your resource groups in. This will be the default location for any resources you create in that resource group. Resources cannot talk across location. API connections you created in one location will not be reusable in another. You cannot share API connections across resource groups.</li> </ul> </li> </ul> <h1> What to watch out for </h1> <ul> <li>Make sure you put some thought into organizing your resource groups <ul> <li>Microsoft has a good guide on naming conventions for you azure resources</li> <li><a href="https://docs.microsoft.com/en-us/azure/architecture/best-practices/naming-conventions">https://docs.microsoft.com/en-us/azure/architecture/best-practices/naming-conventions</a></li> <li>We started off with one resource group to rule them all and found out when we went to go export the resource group, there is a hard limit of 200 resources.</li> <li>Even after splitting resources into their own groups, we still ran into timeouts trying to export resource groups with only ~60 resources.</li> <li>Think about parameterizing your resources early, but be careful, you lose visibility to those values in Logic Apps designer for example. Even when you go into the code view of your Logic Apps, those values could be misleading. You have to export the template of your Logic App to see the actual values being passed in. </li> </ul> </li> <li>Some resources will require more work than others to get into a deployable state. API Management, for example, is a bear to deal with. We're still working on a solution to deal with this. If you're wiring up your endponts to logic apps, you may end up losing connections to your Logic Apps when we deployed to production. </li> </ul> <h1> Deploying resources to your production environment </h1> <ul> <li>We ended up building a CLI that leverages the Azure Resource Manager Az Powershell module which allows us to pull and push resources. We had to make the jump to powershell 6 as well. <ul> <li>We extract the parameters out of the resource and put them in our environment specific parameter JSON file. </li> <li>We setup a git repository to house all of our ARM templates. We discovered the order of properties drastically varied in our ARM templates from export to export, so you may need to run your ARM templates through something that orders your properties. This will makes diffs significantly more readable when you PR to master.</li> </ul> </li> <li>Be careful with the PowerShell Az Module, we ran into issues where our property values did not serialize past a certain depth. While you can configure the depth, pay close attention to your ARM templates before you push to your higher environments.</li> </ul> <h1> Serverless thoughts </h1> <ul> <li>You can only take the cloud tools so far. If it starts to become difficult enforce patterns or track dependencies, you may need to drop down to code. If this becomes the case for you, take a step back and evaluate your options right away.</li> </ul> serverless azure Eric Thu, 29 Aug 2019 04:08:21 +0000 https://dev.to/eromanowski/why-are-moving-away-from-the-transform-connector-liquid-templates-in-azure-logic-apps-hk5 https://dev.to/eromanowski/why-are-moving-away-from-the-transform-connector-liquid-templates-in-azure-logic-apps-hk5 <h1> TLDR </h1> <p>We are working on a project that requires us to regularly transform data from one shape to another for our integrations. We decided liquid templates in the Transform connector in Logic Apps/integration accounts seemed like a reasonable solution. We quickly found out the developer experience is terrible.</p> <p>Be careful, Liquid template syntax in Azure Logic Apps Transform connector varies between the tooling in VS Code. While your transform may work in VS Code, you will often find it doesn't work as expected in Azure. </p> <h1> What did we run into? </h1> <p>The extensions available in VS Code are built on a ruby flavor of liquid templates while the Transform connector is using DotLiquid version 2.0.254 (as of March 11, 2019). There are differences in syntax and capabilities.</p> <ul> <li><p><a href="https://github.com/dotliquid/dotliquid/wiki/DotLiquid-for-Designers">https://github.com/dotliquid/dotliquid/wiki/DotLiquid-for-Designers</a></p></li> <li><p>You'll find that there are more features available in the ruby flavor that don't exist in DotLiquid</p></li> <li> <p>Where did I get that 2.0.254 version? Straight from a response from the Microsoft support team. The problem is that is does not correlate to any release on DotLiquid's Github repo.</p> <ul> <li> <a href="https://github.com/dotliquid/dotliquid/releases">https://github.com/dotliquid/dotliquid/releases</a> </li> <li>Update: I reached out to the top contributor of DotLiquid and he informed me they havent used github releases in quite a while. That version correlates to the nuget version.</li> </ul> </li> </ul> <h1> What did our development/deployment process look like? </h1> <ul> <li>Download VSCode and install Shopify Liquid Preview <img src="https://res.cloudinary.com/practicaldev/image/fetch/s--nhgMe-Ck--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/l2j9lnib3hukwdsq9ygn.png" alt="Alt Text"> </li> <li>Create a repo</li> <li>Branch</li> <li>Create a transform.liquid and transform.liquid.json and start writing transforms! A great developer experience so far.</li> <li>CTL+SHIFT+P to preview your transform against your sample data in your .liquid.json</li> <li>Commit the template and and create a PR</li> <li>Once your PR makes it to master, upload to development azure environment, run your logic app and start feeling the pain</li> <li>If you run into problems, dig into DotLiquid source code and find the feature doesn't exist or the syntax is different <ul> <li><a href="https://github.com/dotliquid/dotliquid">https://github.com/dotliquid/dotliquid</a></li> </ul> </li> <li>Create another "azure" version of your template and try to keep the two in sync</li> <li>Cry on the inside</li> </ul> <h1> Questions for you </h1> <ul> <li>Is anyone else feeling the pain of the transform connector in Logic Apps? If so, what kind of tools have you discovered to improve developer productivity?</li> </ul> <h1> Proposal for Microsoft </h1> <ul> <li>Create a DotLiquid Preview extension that aligns to the version of DotLiquid used in the transform connector</li> <li>Deploy a new Map type to integration accounts (i.e. Liquid-Ruby) and change the configuration property <code>Liquid.UseRubyDateFormat = true;</code> </li> <li>Open source the Transform connector so we can make modifications and extend the capabilities</li> </ul> <h2> Side Notes </h2> <p>This is my first blog post ever. I'm interested to hear your feedback on how I can improve. Any and all feedback is welcome.</p> azure liquidtemplates dotliquid logicapps