DEV Community: Ryan Posener

Thinking about Zipf's law when coding

Ryan Posener — Thu, 30 Jan 2020 00:06:12 +0000

The inspiration

This article started when I watched The Zipf Mystery on YouTube. Michael (aka VSauce) explains Zipf's law in details there. In summary this is just showing that many things naturally follow a logarithmic rate of occurrence. This gives rise to the Pareto Principle aka 80/20 rule which has several impacts within computing code.

My thoughts

As I was thinking about all of this and how it impacts the code that my team commonly writes it struck me where we experience this 80/20 rule everyday. Writing application code is really writing the 80% of the application that is only 20% of the execution.

For Example: If you write a business application using ASP.NET and MVC, what you are doing is adding 80% of the code needed which accomplishes the business goals. That 80% of the code though only accounts for 20% of the application execution.

Now think about the ASP.NET MVC code that our code is built "over". That code is only 20% of the code, but accounts for 80% of the execution - it's executed on every request, not just when the specific function is requested.

Here we can see just how the first 20% accounts for about 80% of the execution. Whereas our 80% is only executed 20% of the time, but it provides the width of functionality that accomplishes the specific business goals.

Take-Away

My take away is that the bulk of developers spend most of our time focusing on the wide business needs. This is very different from creating code that establishes a very effective framework. For some of us that's great - but I think we should all challenge ourselves to dig into the hard stuff and write some framework-capable code. Doing so opens us up to thinking about execution differently.

Why it's hard

It requires starting from zero. This is a different kind of thinking. From blank you must come up with the M-V-C interaction. You must "own" the methodology. Coming up with and reasoning this out is not natural for many of us. We want a framework to work within. Writing a framework requires one to frame the generic problem (e.g. M-V-C = data-presentation-logic separation). Maybe there are still better ways to frame things? Maybe data and logic should not be separated, isn't that the DDD approach? Why does DDD still hide behind M-V-C in Web App development?
You must think about someone else's code. How do you make things work well for them? How can you keep things flexible? How will they think about their problem within your framing?
Documenting your code is very critical. Intellisense comments are critical for the consumer to be able to quickly understand what happens. For example, consider a Car class with a Start() method. Without intellisense, your caller must assume whether you mean Start Moving or just Engine started. If this used only in 1 part of an application that's one thing. But if you're writing framework code, we must assume everyone will need this method, and must understand it's purpose clearly.
Testing absolutely critical. When you write code that will be called so much, you must test into all the edge cases, and capture more as your work progresses. If not, your bugs will account for 80% of the bugs.

Why we should all do this

Writing code and thinking along these lines pushes us to different limits. While I realize this isn't for everyone I do believe everyone can learn from this exercise. If nothing else, it will help us to examine our own coding, testing, and documentation.

Web Components

Ryan Posener — Fri, 24 Jan 2020 15:49:17 +0000

The Web Components standard has been blogged and written about many times. Many suggest the standard is not ready deferring to other popular frameworks. This may be true for some people/teams - particularly those heavily invested in one framework or another. For new teams and projects I strongly recommend taking another look at native Web Components. I am going to present a case that the standard is ready. Remember that Native Web Components are:

Universally compatible with every modern browser. Check the Browser Support here.
The top Frameworks identify them as complimentary (React) , partially supported (Angular), and support as a build/render (Vue) target.
Finally, they are the fastest - nothing can get much faster than using the raw browser APIs.
As I'm going to hopefully show you - easy and simple to use.

What are Web Components
First, let me clarify what the Web Components standard really amounts to. It's a set of APIs to support developing Components for Web Applications that run in the browser. It is not a framework with all the answers - this is just raw APIs. Don't let this turn you off. I'm going to demonstrate how you can accomplish the ease of a framework very easily.

Why stick to a Framework
The plus to picking a framework is that hiring is eased as you can find people good at using your chosen framework. A 3rd party framework also allows your Dev team a resource to look up recipes for how to accomplish a code challenge.

Why use native Web Components
Not using a framework opens you up to more understanding, and frees your team to solve problems. It requires your Architects and Senior Devs to discuss approaches and patterns and practices. Your dev leadership will have to own the approach and teach the other team members instead of relying on another web site or courses to teach an approach dictated by a framework.

Ok, convince me further...
My didactic project is a learning template for developers. It solved many of the same benefits that frameworks are offer you. This goal is to teach you to solve these problems yourself. In the didactic project I intend to show how we can create declarative Web Components which are as isolated or not as you'd like. Web Components that are light weight, fast and intelligently update the DOM. Web Components that use clean and concise code patterns that are SOLID and DRY. Web Components that participate with the HTML and work as an application with visible and observable application data without the need for custom Dev tools. Web Components that are easily bundled and packed and work with every other framework (jQuery, Bootstrap, Angular, React Vue, Etc).

Now show me the code
What you will find is about 300 lines of well-documented code spread across 4 files. That's it and I've created a pattern and solved for many of the same benefits of the big frameworks. I think a new team could learn and understand a bit of code like this in such a manner that they will be as productive using these native APIs. Learning like this also opens the team to extending and growing parts of the code based otherwise typically off limits. This in my opinion can be very freeing and empowering.

Starting with no external dependencies and learning modern browser APIs your team is in a very different place than you find with a team that knows a framework and must look up the APIs. Taking an approach like this will connect the development team with native browser and supports using the tools of your choice.

Didact simply means to teach or instruct. Take 15 minutes to read the couple pages and view the sample components. Currently I have 3 example components, and I'm working on adding more samples. If you have ideas or a challenge in mind for something you'd like to see how it can be accomplished with native Web Component API's - open an issue, clone or fork the code, or send pull request and let's give it a try.

Here's the link again in case you missed it: github.com/rposener/didactic

Thanks for reading my article. I look forward to your feedback on my GitHub project site. Maybe you can create an even better approach or something amazing. If you do, share it! I encourage you to review, learn and share these APIs.

Good to Great with Patterns

Ryan Posener — Fri, 23 Aug 2019 15:10:55 +0000

The Project Pattern

Each project seems to have a pattern. In the .NET world, we typically start with some form of MVC. If you're doing micro-services, then REST becomes a top-priority for the team to agree about. On some projects it's DDD. I feel like no matter the team or project the team gravitates toward establishing a pattern statement like:

We follow the ________ pattern on this project.

It's great to have a team talking patterns. Code is looking clean and organized, things are making sense to new the jr. devs. And they are looking up to mid- and sr. devs who are glad to answer the questions from their vast experience with _____ pattern. Those devs tell stories about it gone wrong, and experiences with teams that did it so much better than this team. The team boasts and prides itself on working this pattern.

These are good devs! This is a good team.

The Pattern is a problem

90% or more of all applications I have worked on use more than 1 pattern. The patterns cross each other, intersect and weave into the code. But there gets to be so much discussion about 1 pattern everything revolves around it. Other patterns are mere after-thoughts. Thus starts the problem...

An Example

The team that starts with MVC building a micro-services architecture which focused on REST endpoints has made everything REST-based. Each element has it's own endpoint supporting GET, POST, PUT, DELETE and the occasional PATCH for each and every object they encounter.

Their application is working with 50 requests to their micro-services per page view to build the up the view, and things start to get slow.

Someone suggests a cache service returning a "composite" object in 1 request to speed things up. It's micro-services, so why not add another query service to do just that? Excellent idea - the team just gave themselves the two hardest questions in computer science.

What they missed

So a new kid joins straight out of DDD training, and dares to ask "why didn't you use DDD and leverage a nice aggregate root". 99% of this code requests everything from these 2 roots, and performs actions aligned to these roots.

Of course, at this point the team quickly dismisses the notion because it's not the REST pattern that we have working. After all that's just how micro-services are supposed to be done.

Take-away

With any project, keep an open eye towards new patterns. Be astute and understand where different patterns are in the code.

This turns a good developer a GREAT developer.

Be constantly asking questions like this to yourself as you code.

Is the JS-code following MVVM?
Is there an aspect of code within that service layer that would benefit from a full DDD approach?
Are repository patterns consistent, or would they just splitting up and confusing an aggregate root?
Is there an n-Tier pattern and if used, how does our Unit-of-Work pattern work?
Is State-Transfer REST the right thing for your application or would it be more logical to use a RPC-style method?

Note: this article on REST confusion is a great read, and covers more specific examples in detail.