become a world class developer

www.aestheticio.com

Become a World Class Developer

Become a World Class Developer by Learning How to Focus On The Things That Really Matter.

AESTHETIC IO

http://www.aestheticio.com

Web App Architecture 101 2 AESTHETIC IO

Copyright © 2014 Stephen Young

All Rights Reserved

Feel free to email, tweet, blog, and pass this ebook around the web ... but please don’t alter any of its contents when you

do. Thanks!

www.aestheticio.com

www.aestheticio.com



ContentsContents 3 How you can get ahead by focusing on principles and not technologies5

Why should you focus on principles and not technologies? 5 Some practical tips. 6 Conclusion 7

15 Questions developers must ask themselves every day. 8 Is there a pattern here? 8 How can I make this simpler? 8 Why does it work like that? 9 Has somebody done this before? 9 Who said it first? 9 Do I love what I’m doing? 10 Where else could I use this? 11 What did I fail at today? 11 How can we make this possible? 11 Who can I learn from? 12 Am I learning the right things? 12 How can I make this more transparent? 13 What is the return on effort? 13 Am I solving the right problem? 13 Does anybody care? 14 Start today 14

12 Attributes of a good web architecture 15 Developer productivity 15 Elegance 15 Usability 16 Security 16 Reliability 16 Performance 17 Scalability 17 Testability 17 Interoperability 18 Transparency and troubleshooting. 18 Community and Product Growth 18

www.aestheticio.com


Web App Architecture 101 4 AESTHETIC IODeployability 19

Why your code is so hard to understand 20 Problem #1, overly complex mental models. 20 Problem #2, poor translation of semantic models into code. 21 Class structure and names. 21 Single responsibility principle (SRP). 22 Appropriate comments. 22 Problem #3, not enough chunking. 22 Problem #4, obscured usage. 23 Problem #5, no clear path between the different models 23 Problem #6, inventing algorithms 24 Conclusion. 24

Learn how to build damn good web apps 25

www.aestheticio.com



How you can get ahead by focusing on principles and not technologies Are you running to stand still?

“Well, in our country,” said Alice, still panting a little, “you’d generally get to somewhere else — if you run very fast for a long time, as we’ve been doing.”

“A slow sort of country!” said the Queen. “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!”

- Lewis Carroll from Alice in Wonderland.

As web app developers you are accustomed to the process of constantly having to learn and adapt to an ever changing technology landscape. It is obvious that to keep your skills relevant and competitive you need to always be up to date with the latest technologies.

Why should you focus on principles and not technologies?

If all you are doing is learning each new technology as it comes out what you are doing is running as fast as you can just to stand still. You need to run faster than that!

So how do you do this?

By looking for the underlying principles and driving forces behind new technologies. Technologies are coming out at an ever increasing pace. If you pay attention you will start to notice the underlying trends that drive this relentless innovation.

What do DCOM, CORBA and Webservices have in common? One similarity is that they are all RPC mechanisms. Each one progressively tries to be more and more

www.aestheticio.com



platform agnostic. They are very different beasts yet they share a few core characteristics.

Since they share characteristics you can safely assume that they will also have some of the same problems in your web app. How do you handle versioning of the RPC call? If you have a large distributed team, how do you limit uncontrolled growth of your remote API’s?

The more you focus on the underlying similarities the larger head start you will have the next time something new comes along.

By all means learn those new web app technologies but don’t just learn the new API, try understand what makes this new solution unique (if anything). Try see how this new solution is just a re-incarnation of a previous one. Over time as you do this you will gain perspective.

Principles like information hiding, decoupling, simplicity and the like are universal and change very slowly if at all. Technologies like Microsoft Application Blocks, Ruby on Rails, the latest IoC container change at a break neck pace.

Some practical tips.

Here are a few tips to keep in mind as you learn a new technology.

Try to answer these questions about each new technology you learn:

• Which older technologies was this inspired by? • Which problems is it trying to solve? • Which other new technologies are also solving the same problems? • How are all these technologies similar? • How do they differ?

Then try to complete this sentence in as few words as possible:

Just like <list of old technologies> <new technology> is <main purpose they all have in common>. Unlike previous attempts <new technology> is <what it is trying to do differently> by <how it’s doing it differently>.

www.aestheticio.com



Conclusion

Any good web app developer eventually starts seeing these trends just based on depth of experience. You can get a head start by actively paying attention.

Are you happy with running to stand still or do you want to get ahead of the pack?

The choice is yours.

www.aestheticio.com



15 Questions developers must ask themselves every day. So you want to be a great developer?

Well then it’s time to put down that “Learn Super Duper Language v8.3 in 24 hours” book. Instead, make it a habit to ask yourself these 10 questions every day.

Is there a pattern here?

Looking for patterns in what works and what doesn’t work leads to discovering the underlying principles that drive seemingly unrelated concepts and behaviours. To get a deeper understanding of the work that you do make it a habit of asking yourself “Is there a pattern here?”.

This applies to more than just your code. Is there a pattern in the types of changes requested by business? Is there a pattern in the way technologies evolve? Are you seeing the same types of bugs popping up again and again?

To understand is to perceive patterns - Isaiah Berlin

How can I make this simpler?

Often as developers we want to produce complex and scalable solutions. Making something tremendously complex makes you feel like the master of your universe. The problem is that you will never be able to predict how your product and business is going to change in the future.

“Architecture” and coding is much more like gardening than architecture. You need to be able to adapt to an ever changing environment. The more complex your solution the more difficult this becomes.

Simplicity is the ultimate sophistication. - Leonardo da Vinci

www.aestheticio.com



Why does it work like that?

Knowing that something works and knowing why it works that way are two very different things. If you know why something behaves the way it does you are able to make significantly better decisions.

The difference between a great coder and somebody who knows a programming language is the depth of understanding that comes from understanding why.

The same principle applies when fixing an issue. “Just restart the service.” “Have you tried rebooting it?” We have all said something along those lines when a problem pops up. Every time you say something like that you lose a golden opportunity to learn.

Understanding why something broke allows you to fix the root cause and eliminate this class of issues permanently. At the very least you won’t make the same mistake again.

Has somebody done this before?

Whenever you find yourself inventing a complex algorithm you are probably on the wrong track. Unless you are busy researching a PHD thesis chances are extremely good that somebody else has already solved this problem.

Need to write an algorithm to add a label to the item closest to a users mouse? Have a look at Voronoi Tesselations. Want to find the shortest path for a delivery truck? Look at Dijkstra. Want to find tags similar to the one the user just entered, how about figuring out it’s Levenschtein distance.

Those are just a few examples but trust me, they are everywhere.

If I have seen further it is by standing on the shoulders of Giants. - Isaac Newton

Who said it first?

www.aestheticio.com



So you think you know REST right?

Have you read Roy Fielding’s original paper describing REST and do you understand it’s intended purpose? That blog post by that guy who has 5 minutes more experience than you using the REST API generation wizard in Super cool IDE v7 doesn’t count.

Do yourself a favour and always try read the original source of a concept or theory. Then by all means go read the latest developments by industry thought leaders but if you don’t know where they started how can you follow where they are going?

Do I love what I’m doing?

Lets face it programming is hard.

Besides being hard programming is constantly evolving. The state of the art framework from 2 years ago is a clunky dinosaur by todays standards. To stay at the top of your game you will need to commit to a lifelong process of learning and research.

If you don’t love what you are doing you don’t have a hope in hell of keeping up with the guys who do. So find out what kind of coding gets you fired up. Don’t decide to become a security specialist because there is a gap in the market or because it pays well, don’t become a UX expert just because an article just came out in WIRED saying that UX is the hottest job in tech.

I’ll say it again, do what you love.

Do what you love and the necessary resources will follow. - Peter McWilliams

www.aestheticio.com



Where else could I use this?

One of the biggest limits I see developers placing on themselves is a failure of imagination.

If we learn something in a specific context or see a technique used to solve a specific problem we assume that’s the only place it applies. This is almost always wrong. Every time you learn something new ask yourself: “Where else could I use this?”.

Found great new positioning methods to place nodes on a graph, how about applying that same technique to find interesting data points in a dataset that has 2 dimensions? Found a cool way to send data over websockets from the client to the server? How would this apply in making a scalable set of backend services? Sometimes you will be wrong, but sometimes you will be right.

Logic will get you from A to Z; imagination will get you everywhere. - Albert Einstein

What did I fail at today?

One of the easiest ways to increase innovation is to lower the cost of failure.

The game developing company Valve has embraced this like few others. The same applies to your progression as a developer, if you are afraid to fail you will never make those big breakthroughs.

Be brave, try something, fail, learn and try again.

Do not fear mistakes. You will know failure. Continue to reach out. - Benjamin Franklin

How can we make this possible?

In the world we live in there really is very little that is impossible (with a few exceptions).

www.aestheticio.com



Start from the assumption that whatever you want to do is possible and then work your way back. You might find that what you wanted to do is impractical for the time being but with the pace of change in todays world, it might become practical sooner than you think.

It always seems impossible until its done. - Nelson Mandela

Who can I learn from?

You should never work anywhere where you are the smartest person in the room.

Pick jobs and companies where you can work with people who inspire you and challenge you to be better. It doesn’t have to be coding related, there is a world outside your text editor and the command line. Learn things from other fields and find ways to apply it in your job.

Being competent isn’t good enough anymore.

Am I learning the right things?

I assume you are already actively learning.

You wouldn’t be reading this post if you didn’t want to learn. Are you learning the right things though?

People often tell me: “I’m learning a new language” and they invariably mention another language just like the one they already know. If you have a toolbox full of hammers rather invest in a screwdriver.

If you know OO, learn a functional language. I recommend Haskell since there is no way to cheat, be warned, your brain might melt a little.

If you have those 2 under the belt check out a logical language like Prolog. Make sure you know a dynamic language like Ruby. And if you get a chance check out APL. It’s beautiful.

www.aestheticio.com



How can I make this more transparent?

The hardest part of fixing a problem is finding it.

Do everything in your power to make your solutions transparent. Write lavish logs, throw exceptional exceptions, make your code clean and sparkly.

Every time you struggle to find a problem make sure the next guy can find it with less effort.

What is the return on effort?

Everything comes at a cost. Not writing that unit test buys you a few minutes right now but at what cost later on? Taking a week to research existing algorithms might save you 3 months in development time by the end of the project.

If it takes you 20 minutes to do a deployment and you do 10 deployments a week, how long until taking those 3 hours to automate it is paid back?

That plugin framework that might possibly save you 2 days one day. Does it make the things you do everyday take 5 minutes longer? How long until those 5 minutes add up to more than those mythical 2 days?

This is a marathon, not a sprint.

Am I solving the right problem?

Writing a script to periodically restart a service to improve stability is awesome. What’s even more awesome is fixing the memory leaks that make the service crash.

Created a marvellous multi threaded app to generate 20 concurrent crystal reports? Nice! Why not investigate a switch to XSL-FO so each report doesn’t take 3 years to generate.

www.aestheticio.com



Question everything.

If you get a set of requirements that don’t solve the right problem. Speak up! You are more than a code typist, you are a problem solver.

Does anybody care?

This is probably the most important one of the lot.

If what you are building doesn’t make somebodies life better, gives them more time, saves them money.

Why are you doing it?

Start today

I know this list is long and it might seem like a lot to take in.

You don’t have to do it all at once though. Try this; find somebody you work with who is also on a mission to be the best they can be. Pick one question per week and commit to asking each other that question at least once a day. Think about your answers, be honest, be better.

Good luck!

www.aestheticio.com



12 Attributes of a good web architecture So you have a working web app but is the architecture any good?

While every solution is unique there are a few attributes that any good architecture should display. If you have been asking yourself the questions I listed previously you should have a solution that shows most of these attributes.

Have a look at your last web app and see how it scores on the list of 10 quality attributes below.

Developer productivity

Since smart people are the most precious resource you have any framework or architecture we adopt needs to help optimize developer productivity time.

Attributes: • Simplicity • Concise but not obtuse • Standardized way of doing things • Great supporting tools • Short feedback loops • Expressiveness • Quality 3rd party packages?

Elegance

The elegance of the solution speaks to how well the solution fits the problem space and how coherent the solution is.

Attributes • Consistent way of solving a problem. • The most common tasks are the easiest to do. • Clear guidance on how to make architectural choices. • Easily extendable in the appropriate places. • As simple as possible but no simpler.

www.aestheticio.com



• Strong cohesion / low coupling • The problem space forms a large percentage of the frameworks solution space

Usability

Usability is vitally important for a number of reasons. It improves trust, customer satisfaction and reduces support costs. Any technology you use should allow you to build a world class user experience.

Attributes • No vendor specific technologies • Support the latest standards • Must provide fast response times in the UI • Allow for use of graphic and charting capabilities • Allow animation where appropriate • Must support A/B testing • Must support analytics

Security

Security is the capability of a system to reduce the chance of malicious or accidental actions outside of the designed usage of the system, and prevent disclosure or loss of information.

Attributes • Passes 3rd party penetration tests • Uses security standards wherever possible • Follows security best practices.

Reliability

Reliability is the ability of a system to continue operating in the expected way over time. Reliability is measured as the probability that a system will not fail and that it will perform its intended function for a specified time interval

Attributes • It doesn’t crash • Autonomic – when it crashes it heals itself • No single point of failure

www.aestheticio.com



Performance

Performance is an indication of the responsiveness of a system to execute specific actions in a given time interval. It can be measured in terms of latency or throughput. Latency is the time taken to respond to any event. Throughput is the number of events that take place in a given amount of time.

Attributes • Support an appropriate level of performance. • Low latency to the UI (< 250 ms for 90% of requests,, <2s for all requests) or

provide mechanisms to compensate (messaging, caching, etc)

Scalability

Scalability is the ability of a system to either handle increases in load without impact on the performance of the system, or the ability to be readily enlarged.

Attributes • We prefer scaling out to scaling up. • Easy to add more processing nodes. • Easy to load balance new nodes. • Each node should be low overhead. • Licensing should not prevent scaling.

Testability

Testability is a measure of how well a system or components allow you to create test criteria and execute tests to determine if the criteria are met.

Attributes • Provide mechanisms to mock data. • Trigger back end processes via scripting. • Batch processes should be fast when using small data sets. • Easy to create known data. • Ability to automate UI testing.

www.aestheticio.com



Interoperability

Do you play well with others? Communication protocols, interfaces, and data formats are the key considerations for interoperability. Standardisation is also an important aspect to be considered when designing an interoperable system.

Attributes • Use open standards where available. • Publish standards where not available. • Provides you with many options when selecting 3’rd party systems

Transparency and troubleshooting.

When something goes wrong how easy is it to track down the error and re-produce it?

Attributes • All errors and important events are logged in a meaningful way • Easily comprehensible stack traces • All data needed to re-produce an error is included in the log • Debug logs can be turned on and off • It should be easy to trace an error all the way through the application.

Community and Product Growth

There should be a strong community behind the product you are using. Having other people who have already solved the problems you are facing is a major factor in how easy a product or framework is to live with.

Attributes • Many plugins and open source projects related to the framework • Active repo on github if it’s open source • Lots of questions and answers on stack overflow. • A Google trends graph that is going up and to the right. • Many books, blogs and tutorials.

www.aestheticio.com



Deployability

Deployment and propagation through different environments is a huge cost. A product that is difficult to deploy requires longer release cycles and makes it harder to respond to change or fix bugs.

Attributes • Automated scriptable deployments • Automated tests are easy to write. • Fast build times. • File based configuration or easily scriptable configuration. • Small physical size. • Licensing should not prevent multiple environments. • Easy rollback

Next time you evaluate a web stack or your app design go through this list and try see if you can tweak your design to tick more of the boxes outlined above.

www.aestheticio.com



Why your code is so hard to understand "What the hell was I thinking?!?"

It's 1:30AM and I am staring at a piece of code I wrote no more than a month ago. At the time it seemed like a work of art. It all made sense. It was elegant and simple and amazing. Not anymore. I have a deadline tomorrow and discovered a bug a few hours ago. What seemed simple and logical at the time just doesn't make sense anymore. Surely if I wrote the code I should be smart enough to understand it?

After one too many experiences like this I started thinking seriously about why my code makes perfect sense while I am writing it but looks like gibberish when I go back to it a few weeks or months later.

Problem #1, overly complex mental models.

The first step in understanding why your code is hard to read when you come back to it after a break is understanding how we mentally model problems. Almost all the code you write is trying to solve a real world problem. Before you can write any code you need to understand the problem you are trying to solve. This is often the hardest step in programming.

In order to solve any real world problem we first need to form a mental model of that problem. Think of this as the intent of your program. Next you need to form a model of a solution that will achieve your programs' intent. Lets call this the semantic model. Never confuse the intent of your program with your solution to that intent. We tend to think primarily in terms of solutions, and often bypass the formation of a model of intent.

Your next step is to form the simplest semantic model possible. This is the second place things can go wrong. If you don't take the time to really understand the problem you are trying to solve you tend to stumble onto a model as you code. If on the other hand you really think about what you are trying to do you can often come up with a much simpler model that is sufficient to achieve your original intent.

www.aestheticio.com



Eliminating as much of this accidental complexity as possible is crucial if you want easy to maintain, simple code. The problems we are trying to solve are complex enough. Don't add to it if you don't have to.

Problem #2, poor translation of semantic models into code.

Once you have formed the best semantic model you can it's time to translate that into code. We'll call this the syntactic model. You are trying to translate the meaning of your semantic model into syntax that a computer can understand.

If you have an amazing semantic model but then mess it up in the translation to code you are going to have a hard time when you need to come back to change your code at a later stage. When you have the semantic model fresh in your mind it's easy to map your code onto it. It's not hard to remember that a variable named "x" is actually the date a record was created and "y" the date it was deleted. When you come back 3 months later you don't have this semantic model in your head so now those same variable names make no sense.

Your task in translating a semantic model into syntax is to try and leave as many clues as possible that will allow you to rebuild the semantic model when you come back at a later time.

So how do you do this?

Class structure and names.

If you are using an OO language try and keep your class structure and names as close to your semantic model as possible. Domain Driven Design is a movement that places extreme importance on this practice. Even if you don't buy into the full DDD approach you should think very carefully about class structure and names. Each class is a clue you leave for yourself and others that will help you re-build your mental model when you return later.

Variable, parameter and method names.

Try avoid generic variable and method names. Don't call a method "Process" when "PaySalesCommision" makes more sense. Don't call a variable "x" when it should

www.aestheticio.com



be "currentContract". Don't have a parameter named "input" when "outstandingInvoices" is better.

Single responsibility principle (SRP).

The SRP is one of the core Object Oriented Design Principles and ties in with good class and variable names. It states that any class or method should do one thing and one thing only. If you want to give classes and methods meaningful names they need to have a single well defined purpose. If a single class reads and writes from your database, calculates sales tax, notifies clients of a sale and generates an invoice you aren't going to have much luck giving it a good name. I often end up refactoring a class because I struggle to give it a short enough name that describes everything it does.

Appropriate comments.

If you need to do something for a reason that isn't made clear in your code have pity on your future self and leave a note describing why you had to do it. Comments tend to get stale quickly so I prefer having the code as self describing as possible and the comments are there to say why you had to do something, not how it was done.

Problem #3, not enough chunking.

Chunking in psychology is defined as the grouping of information as a single entity. So how does this apply to programming? As you gain experience as a developer you start to see repeating patterns that crop up over and over again in your solutions. The highly influential Design Patterns: Elements of Reusable Object-Oriented Software was the first book to list and explain some of these patterns. Chunking doesn't only apply to design patterns and OO though. In functional programming (FP) there are a number of well known standard functions that serve the same purpose. Algorithms are another form of chunking (more on this later).

When you use chunking (design patterns, algorithms and standard functions) appropriately it allows you to stop thinking about how the code you write does something and instead think about what it does. This reduces the distance between your syntactic model (your code) and the semantic model (the model in

www.aestheticio.com



your head). The shorter this distance the easier it is to re-build your mental model when you return to your code at a later stage.

If you are interested in learning more about the functions used in FP have a look at my article on functional programming for web developers.

Problem #4, obscured usage.

Up to now we have mainly spoken about how to structure your classes, methods and variable names. Another important part of your mental model is understanding how these methods are supposed to be used. Once again this is quite clear when you initially form your mental model. When you come back later it's often quite difficult to reconstruct all the intended uses of your classes and methods. Usually this is because different usages are scattered throughout the rest of your program. Sometimes even across many different projects.

This is where I find test cases to be very useful. Besides the obvious benefits associated with knowing if a change broke your code, tests provide a full set of example use cases for your code. Instead of having to trawl through a hundred files, looking for references you can get a full picture just by looking at your tests.

Bear in mind that in order for this to be useful you need to have a complete set of test cases. If your tests only cover some of your intended uses you are going to be in trouble later on if you assume the tests are complete.

Problem #5, no clear path between the different models

Often your code is technically very good, and extremely elegant, but there is a very unnatural jump from program intent to semantic model to code. It's important to consider the transparency of the stack of models you select. The journey from the program intent to semantic model to code needs to be as smooth as possible. You should be able to see all the way through each model to the problem. It may at times be better to choose a particular class structure or algorithm not for its elegance in isolation, but for its ability to connect the various models and leave a natural path towards reconstructing intent. As you go from abstract program intent to concrete code the choices you make should be driven by the clarity with which you're able to represent the more abstract model below it.

www.aestheticio.com



Problem #6, inventing algorithms

Often we as programmers think we are inventing algorithms to solve our problems. This is hardly ever the case. In almost all cases there are existing algorithms that can be put together to solve your problem. Algorithms like Dijkstra's algorithm, levenshtein distance, voronoi tessellations etc. Programming for the most part consists of choosing existing algorithms in the right combination to solve your problem. If you are inventing new algorithms you either don't know the right algorithm or are working on your PhD thesis.

Conclusion.

In the end it boils down to this: as a programmer your goal is to construct the simplest possible semantic model that would solve your problem. Translate that semantic model as closely as possible into a syntactic model (code) and provide as many clues as possible so that whomever looks at your code after you can re-create the same semantic model you originally had in mind.

Imagine you are leaving breadcrumbs behind you as you walk through the brightly lit forest of your code. Trust me, when you need to find your way back later on, that forest is going to seem dark and misty and foreboding.

It sounds simple but in reality it is very difficult to do well.

www.aestheticio.com



Learn how to build damn good web apps Building world class web apps is hard.

Trust me I know, I have been building web apps for the last 15 years. There is a massive amount to know and a new technology comes out almost on a daily basis. This site isn't for people looking for a silver bullet. It's for those of you who love the web and are willing to put in the time and effort required to build your skill set. In the free member library I try and point you in the right direction.

With the eBooks in the library I help you focus on the right things so you don't waste your time.

You will learn:

• How to be better at learning and get a head start. • How focusing on principles gives you an unfair advantage. • How to build skills outside your current role and become more marketable.

Click the “Free Registration” button below, choose your username and password, and sign up for our free membership library. You will get instant access to ebooks about every facet of building damn good web apps.

www.aestheticio.com

Free Registration

Click Here to find out more

http://aestheticio.com/free-member-library





become a world class developer

Documents