[{"_1":2,"_160":-5,"_161":-5},"loaderData",{"_3":4,"_38":-5,"_39":40,"_133":134,"_158":-5,"_159":-5},"root",{"_5":-5,"_6":-5,"_7":8,"_22":23,"_24":25,"_26":27,"_30":31,"_36":37},"user","shoppingCartId","shoppingCart",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":20,"_21":14},"id","no-cart","count",0,"free",true,"updatedAt","","paymentGateway","STRIPE","cartItems",[],"loading","locale","en","readerTheme","light","constants",{"_28":29},"paypalClientId","AX53Cwz8jR6rVVzzZiZNWWXl0dGagi-GZrjG-S3Ua14E5nrKMn7DxDQ730O4R8LusLPp49ALn6aRVaEy","publishers",{"_32":33,"_34":35},"companies",[],"universities",[],"needsLocaleCookieSync",false,"routes/_store+/_readers+/read_/route","routes/_store+/_readers+/read_.$slug/route",{"_41":42,"_67":68,"_124":125,"_131":37,"_132":-7},"book",{"_43":44,"_45":46,"_47":48,"_49":50,"_53":54,"_56":57,"_65":66},"title","LiveCode Advanced Application Architecture","slug","livecodeapparchitecture","metaText","This book teaches an MVC-like approach to be used with LiveCode application development. It goes from zero to a running app using best practices and more! :-D","coverFeatured",{"_51":52},"url","https://d2sofvawe08yqg.cloudfront.net/livecodeapparchitecture/s_featured?1651061199&1651061199","coverFeatured2x",{"_51":55},"https://d2sofvawe08yqg.cloudfront.net/livecodeapparchitecture/s_featured2x?1651061199&1651061199","authors",[58],{"_9":59,"_60":61,"_5":62},"Z2lkOi8vbGVhbnB1Yi9TdG9yZTo6UHJvZHVjdEF1dGhvci82MzIy","name","Andre Garzia",{"_63":64},"username","andregarzia","showReadLinkString","sample","parts",[69],{"_43":44,"_70":16,"_71":12,"_72":73},"description","fileCount","chapters",[74,96,106,116,120],{"_75":76,"_43":77,"_78":79,"_71":80,"_81":82,"_89":-5},"level",2,"on openBook","path","#leanpub-auto-on-openbook",1,"subsections",[83,90,93],{"_75":84,"_43":85,"_70":-5,"_78":86,"_71":80,"_87":-5,"_88":-5,"_89":-5},3,"From hobbyist to pro","#leanpub-auto-from-hobbyist-to-pro","quizType","sectionNum","youtubeId",{"_75":84,"_43":91,"_70":-5,"_78":92,"_71":80,"_87":-5,"_88":-5,"_89":-5},"If I do my job right, I will","#leanpub-auto-if-i-do-my-job-right-i-will",{"_75":84,"_43":94,"_70":-5,"_78":95,"_71":80,"_87":-5,"_88":-5,"_89":-5},"This book roadmap","#leanpub-auto-this-book-roadmap",{"_75":76,"_43":97,"_78":98,"_71":80,"_81":99,"_89":-5},"Code Conventions","#leanpub-auto-code-conventions",[100,103],{"_75":84,"_43":101,"_70":-5,"_78":102,"_71":80,"_87":-5,"_88":-5,"_89":-5},"How to name things","#leanpub-auto-how-to-name-things",{"_75":84,"_43":104,"_70":-5,"_78":105,"_71":80,"_87":-5,"_88":-5,"_89":-5},"How to document your code","#leanpub-auto-how-to-document-your-code",{"_75":76,"_43":107,"_78":108,"_71":80,"_81":109,"_89":-5},"An introduction to MVC","#leanpub-auto-an-introduction-to-mvc",[110,113],{"_75":84,"_43":111,"_70":-5,"_78":112,"_71":80,"_87":-5,"_88":-5,"_89":-5},"MVC in 20 seconds","#leanpub-auto-mvc-in-20-seconds",{"_75":84,"_43":114,"_70":-5,"_78":115,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Summary","#leanpub-auto-summary-1",{"_75":76,"_43":117,"_78":118,"_71":80,"_81":119,"_89":-5},"on closeBook","#leanpub-auto-on-closebook",[],{"_75":76,"_43":121,"_78":122,"_71":80,"_81":123,"_89":-5},"Notes","#leanpub-endnotes",[],"toc",[126,83,90,93,127,100,103,128,110,113,129,130],{"_75":76,"_43":77,"_70":-5,"_78":79,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":97,"_70":-5,"_78":98,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":107,"_70":-5,"_78":108,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":117,"_70":-5,"_78":118,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":121,"_70":-5,"_78":122,"_71":80,"_87":-5,"_88":-5,"_89":-5},"isUnavailableOnline","unavailableMessage","routes/_store+/_readers+/read_.$slug.$chapterId/route",{"_43":44,"_135":136,"_41":137,"_155":-5,"_156":157},"content","

\nNotes

1Check out http://en.wikipedia.org/wiki/Hungarian_notation.↩

\n\n\n

",{"_138":139,"_43":44,"_47":48,"_45":46,"_65":66,"_140":141,"_154":136},"previewContent","

\n \n
- \n Disclaimer\n
- \n Version\n
- \n Intended audience\n
- \n Thanks\n
\n
\n on openBook\n
- \n From hobbyist to pro\n
- \n If I do my job right, I will\n
- \n This book roadmap\n
\n
\n Code Conventions\n
- \n How to name things\n
- \n How to document your code\n
\n
\n An introduction to MVC\n
- \n MVC in 20 seconds\n
- \n Summary\n
\n
\n on closeBook\n
\n Notes\n

\nDisclaimer

\n\n

This is an early release. Send feedback to feedback@andregarzia.com.

\n\n

I will expand the content of this book in the next months, I see this book as a living thing, much like LiveCode IDE.

\n\n

This is the “minimum amount of book” I consider useful enough to make a release. I hope you all enjoy and benefit from it.

\n\n

\nVersion

\n\n

The version you’re reading is the: 2020.08.1

\n\n

I’m using CalVer scheme to create version numbers for this book. They are in the format of <year>.<month>.<release> so the first release in November 2019 is 2019.11.1, if I end up doing a second release in the same month, it will be 2019.11.2.

\n\n

\nIntended audience

\n\n

LiveCode developers who want to learn a more structured way of organizing and reusing their code. This book assumes beginner or intermediate knowledge of LiveCode. If you joined our beloved community recently, there are other resources that will help you get started.

\n\n

\nThanks

\n\n

Thanks to every single member of the LiveCode community. I remember being a newbie in 2004 and joining this outstanding crew full of questions and doubts. You all received me and helped shape my career and life. If I were to thank people personally, I would need Heather to give me a dump of all use-list subscribers from 2004 to 2018 (oh my, it has been over ten years…).

\n\n

You people are just too awesome!

\n\n

Since this is a book, I want to specify a very special friend here in this section: Dan “the man” Shafer. From my early days till today, Dan was always someone I could look for inspiration. I remember meeting him in 2004 and thinking that one day I would like to write books. I have since written many programming books, but I always go back to him for inspiration.

\n\n\n

\"Revolution — Revolution at the speed of thought

\n\n\n

I still consider myself an inventive user more than a developer anyway, and the book above still on my shelf…

\n\n\n\n

\non openBook

\n\n

I’ve been a speaker on LiveCode conferences multiple times speaking about many topics such as web development, game design and application organization. The talk that received the best feedback was the one about application organization during RunRevLive 2013. I remember the smiles from the audience as I moved away from the speaker microphone. That mental image and the kind words received as I left the stage kept rumbling on my mind for a while as I tried to understand why that session was so well received while other sessions were less memorable, then one day late at night, I grokked it!

\n\n

Even though Web development and Game design are very interesting topics, they are not the most common activities in our community. When I gave sessions on web development, those doing that kind of work really enjoyed the session, but those that whose work is not related to the Web were not all that impressed. The same thing happened with game design. Still, application organization is a topic that affects everyone. All LiveCoders, from desktop application developers, to WebMasters, to Game Designers, start with the same felling: “LiveCode is so easy that I don’t really need to organize my stuff!” and then, like instantaneous karma, the regret for not having a defined organisational method comes right back at us while we wonder: “Where did I placed that handler?”.

\n\n

We enjoy throwing stacks around while we’re learning the language. I have stacks so badly designed that they try to hurt you when you look at the code. Those stacks from the early spaghetti days are a huge contrast to what I try to build now. My aim with this book is to codify what I’ve learned as I figured out that my code needed to better organization. I needed it to become easier to maintain, a crucial skill to win in the freelance market. Let us label this improvement of skills going from hobbyist to pro.

\n\n

\nFrom hobbyist to pro

\n\n

If you pick the average sample code contribution by new developers that are learning LiveCode as their first computer programming language and compare it with what the seasoned developers who have business built around the language and have been shipping applications for several years, you will notice a huge difference in both code clarity and organization.

\n\n

Going from hobbyist to pro is not the act of building a business or shipping commercial software, but the act of working using best practices. This book is about exactly this, picking knowledge from seasoned developers and moving so we stop shipping spaghetti code.

\n\n

I don’t claim that I invented the techniques presented here, and lots of seasoned developers will recognize their style throughout the chapters. This book has many techniques in it and while I try to present them as a solid and cohesive architecture, remember that you can tweak things to suit your application. You should tailor the methods shown here to your own needs and not the other way around. With that in mind, lets review the book’s objectives.

\n\n

\nIf I do my job right, I will

\n\n

Present a solid architecture for building application using LiveCode using an MVC-like approach. By the end of the book (if you read everything) you should be able to:

\n\n

Name your variable and handlers with meaningful names.
Correctly place code in stacks.
Divide your application into logical units such as models, views, controllers and libraries.
Have a clear picture where things should be.
Create code that is easy to change as your application scope evolves.
Reuse more and more code as you build more applications.

\n\n

\nThis book roadmap

\n\n

To achieve our aim, we’ll follow a hero’s journey and begin with nothing and work towards a simple address book application by the end of the book. We’ll begin talking about code conventions and then move to explain the programming pattern called MVC. Each chapter begins with some theory explaining the topic at hand and then moves to a practical section where we apply what we learned to building the address book application.

\n\n

Even though I am organizing this book as a brief journey, you will still be able to cherry pick chapters and learn specific topics out of order since your needs or interests may not be in the same order as presented here. Just be aware that I build the sample code with the book order in mind and code from the middle of the book may depend on code from earlier chapters.

\n\n\n

\nCode Conventions

\n\n

The primary objective of code conventions is to produce code that is identical no matter who the author is. Code that follow such conventions are immediately recognizable by developers and easier to maintain in the long run. We could say that code conventions are nothing but codified common sense which is true in hindsight but may not be clear when all you have is an empty stack and no plan. In this chapter we will learn the most common code conventions in our community, and we’ll begin with how to name stuff.

\n\n

\nHow to name things

\n\n

Names should always be descriptive and meaningful. LiveCode is a very verbose language and you should not be afraid of making your variables and handlers even more verbose if this saves your sanity six months from now. Other programming languages from old times had space and memory constraints that forced the developer to use the smallest names.

\n\n

\n
I had a computer that used BASIC and each variable name could have only up to two letters, so you went from variable a to variable zz (and cried a lot while maintaining any code).
\n

\n\n

Many developers that learned to code with similar constraints still name things with cryptic names such as curcont claiming that saving some characters in the variable name is good because they type variable names a lot and typing less will lead them to work faster. Naming the same variable with a name like tCurrentContact makes your code obvious even to people who have never seen it before and is doesn’t require much more typing while presenting many benefits in the long run. We should always name things clearly and avoid using contractions or abbreviations. Don’t be afraid to type more characters, the more descriptive something is, the less code commenting you will need to do later. Lets agree on some guidelines for naming things:

\n\n

Use meaningful names.
Use full words and separate them with a capital letter such as currentContact.
Avoid generic names such as count and choose more specific ones such as numberOfApplesInBasket.\nThe rules above are great, but lets dive deeper and focus on how to name variables.

\n\n

\nNaming variables

\n\n

In the LiveCode community it is very common to use Hungarian Notation¹ to name variables as explained in the Fourth World Scripting Style Guide. This method of naming variables advocates for the usage of prefixes and suffixes in the variable name to make the variable type and scope clear.

\n\n

In LiveCode we have global, script local, and temporary variables. Constants are like variables, but they can’t be changed once assigned. Let us mark each scope with a prefix in the variable name:

\n\n

\ng for global variable: such as gApplicationVersion.
\ns for script local variable: as in sDatabaseConnectionID.
\nt for temporary variable: like: tCurrentContact.
\np for parameters: if the variable is passed as a parameter to a handler. Example: pContactA.
\nk for constant: sometimes we also use ALL CAPS and underscores as separators for constants: kUPDATE_URL.

\n\n

Another important caveat is that there is no way to tell if a variable is an array or not in LiveCode just by looking at the variable name, so we usually use a capital A suffix for array variable names as in this example: gAllContactsA which is a global array variable holding all contacts for an application.

\n\n\n\n

Example:

\n\n

1 global gAllContactsA\n2 local sCurrentContactA\n3 \n4 command sayHi pContactA\n5 \tlocal tGreeting\n6 \tput “Hello,” && pContactA[“name”] into tGreeting\n7 \treturn tGreeting\n8 end sayHi\n

\n\n\n\n

\nNaming handlers

\n\n

Some people take a great care when naming their variables and then let all this care go down the drain when naming their handlers. If you think most of your code ends up as being variable names and handler names, you notice that using some wisdom when naming them will pay well in the long run. Some guidelines for handler names:

\n\n

Always place a verb in the handler’s name as in placeFruitInBasket instead of fruitBasket.
Be descriptive, use names as long as they need to be.

\n\n

I have a handler called checkApplicationVersionAndUpdateIfNeeded and I think it is a great name because it instantly tells me what that handler does.

\n\n

Example:

\n\n

1 function getContactDataAsJSON\n2 \t// do something\n3 end getContactDataAsJSON\n4 \n5 command emailCurrentSelectedContact\n6 \t// do something\n7 end emailCurrentSelectedContact\n

\n\n\n\n

We should not underestimate how useful a good name is. Select your verb well and if possible use it as the first word of the handler. As a mental exercise, consider the code below:

\n\n

1 put contacts() into tContactsA\n

\n\n\n\n

From that code there is not much we can infer about what contacts() does. Does it accept a parameter? Is it a function to set something or to retrieve something or both? Unless we have comments in the source code, we must read the implementation of that function to understand what it is doing. Better naming could solve this.

\n\n

1 put getAllContacts() into tContactsA\n

\n\n\n\n

Not only we know what it does since it uses the verb get but we know it retrieves all contacts and not just some selection. Another important naming convention for handlers is regarding their scope. In LiveCode we can have both public and private handlers. If you’re building code that will be shared, such as a library, then you’d create a public API that is documented and available for others, and a private API that is used only by you. Handlers should not call private handlers of other stacks. And yes, now that we have private and public keywords, there is no way to leak the implementation handlers anymore, but still naming them differently helps with maintenance.

\n\n

Lets use an underscore character before the name of any private handler. So if you have a public command called saveContact and this command makes use of the private command writeContactToFile then you should name the private handler _writeContactToFile like in:

\n\n

1 on saveContact pContactA\n2 \tcombine pContactA by cr and tab\n3 \t_writeContactToFile pContactA\n4 end saveContact\n

\n\n\n\n

So just by looking at that source code we know that _writeContactToFile is a private command. Sometimes, naming something wisely is not enough to convey why something is happening in the source code. For these cases we have source code documentation.

\n\n

\nHow to document your code

\n\n

There should be a book dedicated only to teaching how to document code. I suspect developers hate to write documentation because it causes them to think about the same problem twice, once when coding and again when documenting. There are some great tools to help you document your application such as screensteps but this section is not about documenting your application for your end user (one task that screensteps excels on) but to create comments alongside the source code to better explain what is going on.

\n\n

The rule of thumb for code comments is not to explain what is happening but why it is happening. The developer can understand what is going on from reading the source code, but they may need some help to understand why it should work that way. For example, consider the poor case of commenting below:

\n\n

1 function addTwo pNumber\n2 \t// below we add two to a number\n3 \tadd 2 to pNumber\n4 \treturn pNumber\n5 end addTwo\n

\n\n\n\n

That comment is useless because it doesn’t help the developer at all. Now consider the following better example of commenting:

\n\n

1 function movePlayerDown @pPlayerLongID\n2 \t// We add 48 pixels to the value of\n3 \t// top because our game tiles are 48 pixels\n4 \t// tall, so adding this value moves\n5 \t// the player one tile down.\n6 \tadd 48 to the top of pPlayerLongID\n7 end movePlayerDown\n

\n\n\n\n

If at anytime in your source code something is not clear why it should be that way, then it is a good time to write a comment explaining the reasons behind how that code needs to be the way it is. There is no such thing as excessive commenting if all your comments are excellent quality (mark this affirmation as my opinion as this is a controversial topic). The more code conventions and comments you use, the less you will need to remember when it is time for you to fix something in your app.

\n\n

\nTools that use comments for the greater good

\n\n

There are some great tools out there that use source code comments to build amazing things.

\n\n

There is lcTaskList that allows you to leave comments with markings such as TODO, FIXME and build reports on the notes you left for yourself. There is also NativeDoc which is a documentation generator for LiveCode that picks comments structured in a specific way and builds HTML documentation from it. I’ve also built RevDoc a little plugin similar to NativeDoc. You can check more in RevUp 64.

\n\n

\nSummary

\n\n

In this chapter we’ve learned:

\n\n

The importance of good names and conventions.
That by using prefixes and suffixes in variable names we can convey scope and nature.
That by being verbose and always using a verb in handlers names we can make our intention (and code) clearer.
That source code commenting helps developers understand why something is happening and not just how.

\n\n

The next chapter we’ll talk about MVC, a mindset and strategy that is very successful in shipping maintainable code.

\n\n\n

\nAn introduction to MVC

\n\n

The objective of the MVC paradigm is to enforce loose coupling between the representation of information and how the user interacts with it, so the developer can more easily change one without breaking the other.

\n\n

By loose coupling I mean that your application is divided into units (that in the MVC paradigm we call models, views and controllers) that are not dependent on each other in a hardcoded way. This means separating the way things are stored and retrieved (aka model) from your business logic (aka controller) from the way you display your application (aka view). If you follow this separation, you will be able to change each unit with minimal change to the surrounding units.

\n\n

To achieve this separation, we should follow the law of Demeter which states that each of our application units should only have limited knowledge about the other units and restrict its interactions to its closest friends. For example, in a complex application with an address book module and a project management module, each module should restrict its interactions to themselves. The project management module should not go changing the data from the address book module without talking to it. The law of Demeter helps us avoid the difficult debugging problem of figuring out where something was changed.

\n\n\n\n

We can think of MVC as a way to untangle our stacks moving from the usual spaghetti-approaching state towards a neat and organized future. Since we’re speaking about stacks, lets draw out some plans to explain how MVC applies to a project. As we progress in this book we’ll build a simple address book example that will be divided into units called model, view, controller and libraries. Each of these units is a different stack and will deal with a distinct problem.

\n\n

\n
MVC & OOP: The MVC paradigm was created alongside the Object-Oriented Programming which is one of the main paradigms to approach programing. LiveCode is not an OOP language in the classical sense as understood by SmallTalk developers, but that does not mean we can’t leverage what we can from the MVC way of doing things when creating our own applications.
\n

\n\n

\nMVC in 20 seconds

\n\n\n

\n\n\n

\nThe model

\n\n

Our address book model will load, save and manipulate address book contacts data. We will define an API that the other units will use. How we implement this contact manipulation is of no concern to them. We could even have more than one model for the same data type but with different implementation, such as a model that saves to a database, a model that saves to text files, and a model that saves to a remote server. As long as we implement the same public API, we can change the internals of the model without touching the other units. In the classic MVC implementation, the Model will notify interested parties if the data changes.

\n\n

\nThe controller

\n\n

The controller is a stack that holds your business logic. While the model knows how to manipulate contact data, it doesn’t know why or when it should manipulate it. The controller talks to the model, like a transit cop directing traffic to and from the model to the other units.

\n\n

In the classic MVC implementation, the controller gets input from keyboard and mouse or whatever input gizmo you are using and decide what to do with it. It talks directly to the model, telling it what it should do the data. It can also talk directly to the view, since some input may require stuff in the view to change.

\n\n

\nThe view

\n\n

The view is the presentation layer with your cards and controls. The user sees and interacts with the view and the view talks only to the controller, which talks to the model.

\n\n

This way you can try different views and layouts without touching your business logic because that code is on the controller. When you’re building cross-platform applications, you can build multiple views to create interfaces suitable for the various form factors you’re deploying to, like desktop, tablets, and smartphones, all from a single application source.

\n\n

In traditional MVC implementations, the model uses broadcasting techniques to inform the views when data changes. In this loose coupling, the model has no idea what inside the view needs changing; it is just broadcast to all interested parties that they should act upon data change.

\n\n

\nLibraries

\n\n

It is good practice to build code that is reusable beyond your current application development. Libraries are not tied to the business logic of your application, making them the most reusable pieces of our softwares. The more generic looking code that you can build into libraries, the easier your development will be.

\n\n

As an example, suppose you have a function that picks a name like andré alves garzia and converts it to TitleCase like André Alves Garzia. This function is useful for the address book application and many other applications, so it could be part of a library and reused in other projects.

\n\n

\nSummary

\n\n

This was just an at a glance introduction to MVC. Each chapter now will dive deeper into one of these concepts, starting with models. By each chapter’s end, we’ll have one unit ready and be closer to the finished address book application. This small chapter had a bunch of links in it. You should check them all.\nNow, lets see what how we make models.

\n\n\n

\non closeBook

\n\n

This is the end of the book, I know I want more too. In the next months I plan to do more releases of this book, not only because I am sure I will need to issue erratas but also because there is much more to cover. This was the minimal set of features and discussion I felt was needed to move a beginner LiveCoder into a more seasoned developer experience.

\n\n

By reaching this point of the book and examining the bundled source code, you should be comfortable with the following things:

\n\n

\nNaming anything under the sun! You should be an expert namer now, and both your variables, stacks, and handlers should all use descriptive and meaningful names, all cohesive with the development experience youâ€™re building.
\nHow to document your code to save precious time as you forget how stuff was made in the first place and, or, need to on-board more developers into your project. The reasons behind your coding choices should now be apparent not only in the code itself but in the accompanying code comments.
\nSplitting your code into the MVC pattern making all the units loose coupled to each other by leveraging the message path and useful patterns such as the publisher/subscriber pattern.

\n\n

This has been a quick journey but I hope it was worth it for you, I know I am sure it has been worth for me. Please reach out to me with comments, feedback and request for new topics or clarification. My email for this book is feedback@andregarzia.com.

\n\n

Writing this book has been a great experience for me and Iâ€™d really appreciate more feedback about it.

\n\n

I’d love to write more books. I see myself more as a writer than a developer these days. If you like my work and would like like to support me buy me a coffee at ko-fi.

\n\n

See you all around!

\n\n

Andre

\nNotes

1Check out http://en.wikipedia.org/wiki/Hungarian_notation.↩

\n\n\n

\n\n

\n\n","tocStructure",[142,143,144,145,146,147,148,149,150,151,152,153],{"_75":76,"_43":77,"_70":-5,"_78":79,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":85,"_70":-5,"_78":86,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":91,"_70":-5,"_78":92,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":94,"_70":-5,"_78":95,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":97,"_70":-5,"_78":98,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":101,"_70":-5,"_78":102,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":104,"_70":-5,"_78":105,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":107,"_70":-5,"_78":108,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":111,"_70":-5,"_78":112,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":114,"_70":-5,"_78":115,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":117,"_70":-5,"_78":118,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":121,"_70":-5,"_78":122,"_71":80,"_87":-5,"_88":-5,"_89":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

\nNotes

Table of Contents

\nDisclaimer

\nVersion

\nIntended audience

\nThanks

\non openBook

\nFrom hobbyist to pro

\nIf I do my job right, I will

\nThis book roadmap

\nCode Conventions

\nHow to name things

\nNaming variables

\nNaming handlers

\nHow to document your code

\nTools that use comments for the greater good

\nSummary

\nAn introduction to MVC

\nMVC in 20 seconds

\nThe model

\nThe controller

\nThe view

\nLibraries

\nSummary

\non closeBook

\nNotes