See it in action

You can now have it. I’ve tried it on both IntelliJ IDEA and WebStorm successfully. It should most likely work on our other IDE’s too (PhpStorm, PyCharm).

To install:

1. Download Web Browser Connector plugin for JetBrains plugin repo. This is needed for the actual Instant HTML editing plugin.

2. Download Instant HTML editing plugin.

3. Open up WebStorm (or IDEA) and click on Preferences. Search for ‘plugin’

4. Install the plugins previously downloaded from disk. First install the Web Browser Connector*

5. Restart WebStorm (or IntelliJ)

6. Open up your Web Project. Under the Run menu select Instant HTML editing

7. Launch Chrome**. If all has gone well you should now see this below the URL bar

As you make changes (to both HTML and CSS) you should now be able to see them updating live in Chrome.

It’s still early days of the plugin so there might be quirks with it, but I’m sure Vladmir will appreciate any and all feedback.

* You could in principle just install this directly from WebStorm by clicking on Browse Repositories without having to download. However for some reason, Web Browser Connector is not listed.

** Currently only works in Chrome.

I don’t get what BDD offers me over TDD

and it usually is in the context of some framework. I had this happen the other day and like many things that take place on Twitter, it led to more conversations about what BDD is and what it means to different people.

far from the horse’s mouth

Dan North coined the term BDD many years ago, and I by no means aim to redefine it. As such, nothing of what I claim here necessarily coincides with Dan’s definition. This post is exclusively my own opinion. My only certainty is that he at least somewhat agrees with me on this statement:

Dan’s paper taught me a few things and confirmed that other things I was doing were on the right track:

It’s about communication

First and foremost: communication, at all levels.  It is talking to the customer, the business, understanding their needs, asking them why they need that feature, 5 times to make sure they really do. Understanding what exactly the feature is, understanding who it is that needs the feature.

Writing the Story cards in a specific format is about asking the right questions, not having a pretty format on a Kanban board or in a Cucumber test.

Whether your customer is the business owner or a developer, is irrelevant. The only difference is the context changes. Whereby a customer doesn’t care about the term exception appearing in a story, but does care about an error page, a developer cares about an exception being part of the text.

It’s about specifications

The tests I write are about defining the specification of the system. They are the documentation, they are the contract. As my system updates, so do my tests, my specifications. I make no distinction between a user interface or a call to a message queue. They are all specifications.

Misconceptions I have seen

Some things which I feel are misconceptions (or at least what I don’t necessarily agree with), and are somewhat putting people on the wrong track:

BDD is a framework

Dan came out with JBehave in an attempt to dissociate Test Driven Design with Testing. To make his students focus on using TDD as a means in defining the behavior of the software they were writing, and prevent a continuous focus on testing.

As such, nothing forces people into using a BDD framework, because there really is no such thing. Unfortunately the continuous appearance of more and more so-called “BDD Frameworks” and guidance as the one below, do not help

Much like BDD is not about frameworks, it is also not about keywords or flavors.

BDD is for defining system behavior

Dan emphasizes the word behavior and this is also apparent in the naming of the framework JBehave. This often leads to comments of the type:

I use BDD to define more the system’s behavior and use TDD for lower level components

Every single part of a system, from the user interface, down to the individual method on a class has behavior. As such, saying one is for defining behavior and another for defining <insert_alternative_to_behavior_here> makes little sense.

Software has specifications. We define specifications.

BDD is for Business Applications

Here is a common meme

I use BDD for Business applications. For libraries I use TDD

Assuming that BDD is defining a specification, why is that a library does not require its specification to be defined? Maybe the answer to that question is the next item:

BDD is too explicit

BDD frameworks are too explicit. They are too verbose. For Customers this is great, but for developers it’s too much to cope with

How is more bad?

Most likely because we assume that developers are smarter, they are more familiar with the domain they are working in. Yes. Every developer has seen a DAL. Every developer has worked with that specific logging component. Every developer has worked with that specific Message queue. They don’t expect detailed specification of how the libraries work, they just assume things. There’s that word again: assumption.

Everyone agrees that 100% test coverage or all tests green mean nothing. You could have everything working, but have the wrong thing working. The only one that can truly confirm that something is correct is the person asking for it: the consumer.

As such, if we look at a unit test that passes, with no clear description of what the unit does other than the code in it, what have we got to contrast it against? That is why specifying the conditions under which an action takes place, describing the action taking place and defining the expected results serve as a means to verify that the code is doing what the specification is describing.

In Business applications it is true that not all developers are familiar with the domain they work on. However, in software development, where the domain is software, this also holds true. Or you’re telling me that you’re familiar with ReSharper’s PSI subsystem?

BDD frameworks are for higher level, TDD for lower level components

This is not only again making a distinction between types of frameworks, but it is also making the assumption that somehow higher level aspects of an application are different than lower level aspects.

BDD frameworks are for end users to use

Frameworks such as Cucumber which allow for nicely formatted and descriptive specifications, have led many to believe that customers can end up writing these without the intervention of developers. If communication is key, how can we even begin to imagine that this would be a good idea? Who is there to ask the questions?

BDD is for Integration Testing, TDD is Unit Testing

If we accept the term Integration of testing more than one real component of the system at the same time, then BDD is no more of integration test than TDD is depending on the school of thought you follow (i.e. do I mock or do I not mock).

BDD is GWT, TDD is AAA

AAA is the typical pattern for unit testing: Arrange, Act and Assert, whereby you setup the unit under test, execute the action and verify the result.

arrange

act

assert

GWT stands for Given, When, Then, which is usually identified with BDD frameworks

given_a_series_of_conditions

when_I_do_something

then_something_happens

If you look closely, you can see that there is no real difference between the two. Both are about setting up scenarios, executing and validating. The only difference is one is more explicit.

TDD is one assert, BDD has more

There is a spoken rule in Unit Testing that states there should only be one Assert per test. The main reason for this is so that when the test fails, you know where its failed.

There is nothing in the “BDD World” that indicates that a test should have more than one assertion. However, if we consider tests for what they are, which is specification, depending on the level at which we are located, i.e. are we talking about user interaction or method calls, there is a potential for more than one result from an action.

For instance:

when a user tries to log in to a web site with invalid credentials, he/she should receive an error message and the administrator should get notified.

This specification clearly demands two verifications be made.

Applying the same techniques to a method call:

when executing GetCustomerById with an invalid customer, it should return null

only requires one assertion.

Doing this does not necessarily make it harder to detect where a failure is. Some frameworks make this easier than others.  For instance, in MSpec, the above test could look something like the following:

public class when_user_logs_in_with_invalid_credentials {
  Establish context => {....}
  Because of => {...}
  It should_redirect_to_error_page => { // One assert only }
  It should_notify_administrador => { // One assert only }
}

Each verification block (It) usually only has one assertion.

BDD is outside-in. TDD is inside-out

From the time it clicked for me that TDD was about writing specifications, I have always taken an outside-in approach when developing systems. I start with the most external “component” which usually is the user interaction (not UI, but what the UI interacts with such as a Controller in a web application) and start driving the specifications from there inwards. From there I specify internal components and so on and so forth. This allows me to have a usage scenario for every component.

The alternative approach (could be called inside-out) is to start driving out individual components of the system and putting them together. However, if TDD is about trying out a component to see if it fits the need, how could this possibly work if we are not basing the prototyping on an real usage scenario?

Do frameworks really not matter?

I started this post pointing to the unnecessary divide between TDD/BDD frameworks and have kept repeating that I am against the BDD vs TDD framework distinction, specially considering that I see no distinction between TDD/BDD.

Having said that, some frameworks make certain things easier, such as built-in support for multiple verification blocks (MSpec), nicely formatted printouts that can be used as specifications which can be understood by all people, technical and non-technical (MSpec, Cucumber). Some also have downsides. For instance MSpec doesn’t support very well the concept of multiple-input testing.

I normally stick to one framework. If you want to use two, use two, but stop focusing the distinction on TDD vs BDD or on more vs less verbosity.

what i strive for

Dan North gave the following definition of BDD in November 2009, in London:

BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

Whether what I do fits in with that or not, I’m not too worried about.

What is important for me is that when someone else looks at my project, if it is a business application, they clearly, without having to make any assumptions, understand how things work. When they look at my API specifications, they serve as documentation and live examples of how to use my library.

My concern is to perfect this, and over the years, as I come back to projects I’ve worked on, I see the mistakes I’ve made (mostly in the form of assumptions, other times in the form of organization of specifications) and I try and improve it on every new project.

There is no difference between BDD and TDD frameworks because there is no difference between BDD and TDD. It’s just doing things right.

And if I got this whole BDD thing wrong, my bad. However,  I’m not chasing an acronym.

The problem

Here is the problem:

In this case it is a controller, but it can well be any other type of class.

Dependency Injection does not solve tight coupling

Why is this a problem? After all, we are applying Dependency Injection.

We are, but we are not decoupling classes. All we are doing is allowing a specific implementation to be swapped out easily. Whether we’re doing it because we want to change behaviors in tests or at runtime, all we’re doing is avoiding depending on a specific implementation.

What we are not doing is automagically making our code clean and sustainable.

The more dependencies our class takes in, the higher its efferent coupling to other classes, meaning that it knows a little bit too much. If it knows too much, it is  most likely because it is also doing too much. The class is no longer focused on one thing, and as a consequence we are creating somewhat brittle software that is too tightly coupled, even if we are passing in our dependencies, even if we are not using new anymore.

How did we get here?

We all agree that DI is good and so is Composition over Inheritance. And this causes us to end up with classes that act as coordinators or require information or perform actions on these different classes. Other times we end up here because of:

Framework impositions

Often, frameworks impose restrictions that take us down the wrong path. Such is the case of ASP.NET MVC when using the default routing conventions. We mostly encapsulate functionality under a specific controller because the routing suites us. In other words, from a user’s perspective it makes sense to have many things under the /checkout/{action} path, even if that leads us to bloated controllers that take many dependencies which have little to do with each other.

The example I put was one of a Controller having too many dependencies, and I was asked a few times how to avoid this problem. The purpose of the blog post was not around this issue itself but around test setups. However, it is a valid question, and one that has been raised over the past months questioning the usage of IoC Containers.

So I wonder, do you think this is a problem? If so, how many dependencies is too many? How would you avoid it?

The problem however is that often this kind of encapsulation is hiding an underlying design problem.

As an example, I’m going to use one of my all time favorite code-bases that I reference in talks I give on MVC and design in general:

Look at the Authenticated_Shipping_With_EmtpyCart test. It’s short and straightforward. However, notice how the test class has a TestBase:

I chopped off the remaining part as it wouldn’t fit on the screen. You can see the entire class here.  It’s just wrong on so many levels.

If you look at the controller this is testing (CheckoutController), you’ll see:

If I were to write that out every time I would need to test the controller, alarm signals would raise that I’m doing something wrong. If I’m hiding it away in a base class or a method, it’s harder to notice. 

So next time you feel the urge to encapsulate some setup in a method or base class, ask yourself why. If you don’t come up with a good reason, re-think your design.

Side-note: Some people have lately been complaining that IoC Containers lead to these kind of design smells also, allowing developers to by injection-happy when dealing with dependencies. It might be true, although I believe that if you are correctly writing the necessary tests, you’d notice this problem early on. The code above also uses a container in the tests (and doesn’t even use conventions for setting it up). That’s another reason I’m against using containers in unit tests.

For quite a few number of years, I’ve switched my mail over entirely to GMail. By that, I don’t mean just using the Web Interface, but also making my @gmail.com address my primary one. Prior to that, I was using (and still handing out sometimes) my own domain address (@hadihariri.com).

Although GMail allows management of multiple accounts* when sending out emails, for a variety of reasons, including preventing setting up multiple accounts on different devices and apps, I made my @gmail.com account the default. This meant that every time I’d send out new email or respond to one, it would be sent out through my @gmail.com address.

Everyone was using GMail and handing out GMail accounts left and right, why shouldn’t I?

Even though I’d switched to GMail, for some time I was still using desktop apps for email, accessing GMail via POP/IMAP. And when it comes to these, I’ve tried them all, be it Outlook Express, then  Outlook, then The Bat, and so on and so forth. My main concern was having access to my email, be it whether I was traveling and didn’t have a connection or for back-up purposes. However, at some point, after being fed up with Outlook PST corrupt files, I gave up and went fully-fledge web. I thought, well Google’s going to do a hell of a better job of storing my email than I would, so forget this whole backup nonsense. Plus, GMail now offered a pretty decent offline experience, so win-win.

*[If you’re not familiar with this, you can change the setting under Settings | Account]

Solving offline experience and backups

Despite Google never going down and having my mail backed up, the thought that all my email was somewhere where one day I could lose access to it, still haunted me. One solution I came up with was to enable offline storage of GMail for the maximum amount of time possible. Back then this was around 5 years. Guess what? It didn’t work. The experience became horrible (and yes they did warn you). Even with a connection, searching was horrendous. And on slow connections, it was dreadful. I soon gave up on that.

My other option was to use some third-party cloud service to back-up, giving them access to my GMail account. Something just didn’t entice me about that however.

The local backup

Having had Thunderbird installed for a secondary account I manage, I decided to switch back to desktop app for a while. So I set up GMail to use IMAP and all was good. I didn’t last though. A lot of the features in the Web interface made working with mail much easier (grouped conversations, labels, etc.).

However, I did solve my backup problem. I configured Thunderbird to sync all messages and keep local copies:

Every day or every other day, I open up Thunderbird and let it churn away syncing my account. I now combine this with CrashPlan which then backs up my Thunderbird folders in the cloud.

All is good

All seemed good. I had my email backed up in three different places, GMail, my local machine and CrashPlan’s servers. I even had offline experience when I wanted using Thunderbird. What could possibly go wrong?

30 seconds turned into more than 24 hours.

Last week, I lost access to GMail for nearly a day and a half. What was quite scary about it was that for the first 12 hours, it seemed I was the only one. Nobody else was having problems despite multiple times asking on Twitter and Googe+.

At some point though I felt more relieved finding out I was not alone:

Realizing this could actually last for some time, I logged into my domain provider and stopped the forwarding of my @hadihariri.com accounts to @gmail.com. I created individual accounts for them and started using the Web Mail to access these. But guess what? Out of the more than +100 emails that were piled up in the short interval I had no access, only around 5-6 came through to my @hadihariri.com domains.

That’s when it struck me. Reaching me was in Google’s control.

Big deal. You lost email for 24 hours

Now you might be thinking that this isn’t such a big deal. That losing email for a day is not the end of the world. It is not. I could have actually been quite productive that day if I hadn’t been so concerned about reaching my email. However, what it made me realize is that I am dependent on Google to be reached.  Having switched over to GMail fully, and giving out my GMail account as the primary one, Google now controlled if and when people could reach me.

Now although GMail does not go down very often, and even if we consider they’d never terminate the free service (at some point when I read the TOS, it indicated that they could stop providing the service when they wanted to), there is always the possibility that Google can explicitly terminate your account, or block it for some unknown reason. I don’t have to link to explicit stories, but I’m sure if you search for accounts being blocked or deleted, you’ll come up with a ton of stories. And if none of that occurs, there is always the risk of someone hacking your account and deleting it.

In other words, your net existence, specially if you’re not very “social” and have Twitter, Facebook accounts, is exclusively in Google’s hands.

The sad thing about this is, that in my case, I put it there.

Steps to take

After this occurred, I took a few steps. I stopped making @gmail.com my default Reply-From and switched back to using my @hadihariri.com domain. I also took a few other steps, which I’d recommend you consider too:

• Have a backup plan. Don’t rely exclusively on your mail provider. Whether you trust having a cloud service backup your email or go down the route I’ve taken to backup locally, doesn’t matter. But have a backup.
• Make sure you own the identity you hand out. Have your own domain, specially if you are a business. Sure, you might lose your domain, but the chances of that happening are slim. And domains aren’t locked to providers.
• Secure your account. If using Google, enable two-step verification. Also, try and limit who can and cannot access your Google identity as an OpenID provider. Don’t just trust any application.
• Provide your domain account as your password recovery. One other step I took was change some of the social networks I’m signed up to and provide an alternate email account for access/password recovery. In fact, even GMail asks for this. Make sure you don’t lock it to @gmail.com since many services require confirmation of change of email address and if you lose access, you can’t do it.

Of course, everything I say can be applied to Google, Hotmail, Yahoo or any other service providing you with a primary email address. It is far from my intention to single out Google or make Google look evil. I am the primary person responsible for these mistakes.

And while I hope I won’t have to experience this again, I am glad I did. It was my wake-up call.

• ASP.NET MVC is a framework that allows you to create applications based on HTTP.
• WebAPI is a framework that allows you to create applications based on HTTP.

So now, under one roof (the roof being ASP.NET MVC not ASP.NET which would have made a bit more sense) you can use two distinct technologies to create HTTP-based applications. Note that I’m talking about HTTP, not necessarily what one would call RESTful systems, but plain HTTP.

Two choices, what to do?

Which one to choose from though? Well, the problem with that question (or maybe a somewhat answer) is that neither of the two technologies is complete. Each have their own missing features and benefits.

With ASP.NET MVC, out of the box, you don’t get things like Content Negotiation, Support for Conditional GETs or PUTs, Complete HTTP Response codes, HTTP Authentication, among other things. And in case you’re wanting to take a resource approach, well you’re out of luck there too since MVC is focused around operations not resources. You do get nice support for View Engines though.

On the other hand, with WebAPI, you do get some of the previous things, mainly Content Negotiation and a more Resource orientated approach (or so it has been said). You also get self-hosting capabilities and are more “exposed” to the raw HTTP. But, you don’t get a View Engine. What this means is that you can’t easily throw together some template in Razor and have it display to in a browser as a user interface.

The Microsoft Guidance

The general guidance coming out of Microsoft, be it from blog posts, tutorials or generally what members of the ASP.NET team are recommending, is to use the best of both worlds. That is, use MVC to create your user interface and use WebAPI to create your API. You can have a CustomerController to handle the HTML views and interaction with real humans, and have an CustomerAPIController (or whatever is may be called) to deal with non-human software interacting with your system. There are wizards in the product to create the different types of controllers and the main debate going on seems to focus more around what folder each type of controller should reside in. It is also mostly being defended under the Separation of Concerns Act.

To be clear, it is recommended to:

• Create your user interface with MVC
• Create your API with WebAPI

There is no division

When you’re creating an application based on HTTP, your application protocol, that is the language that is used to communicate between your application and the consumer of your application is HTTP. HTTP is not a mere conduit to transfer information. It is a fully fledged application protocol.  It has operations, it has request headers, it has responses and response code. It knows how to deal with stale data, it knows how to deal with authentication. It knows what resources are and how to represent these in different way. It is your API.

If you take this into account, your User Interface, is nothing more than another consumer of your API. When you request to see a Customer, if you are a human being, you will be presented with an HTML page to see the customer record. When you are a machine you can request a JSON or XML variant of that customer. However, these are merely two different representations of the same thing. When you update  a customer, be it via a user inputing data into a form, or a machine submitting a POST request, there should be no distinction in the behavior of your application. Why would there by? And if there isn’t, why add an extra overhead of separating them out? It makes no sense whatsoever to try and artificially separate these two concepts out into UI and an API. The only UI thing you need to do on the server is forms and HTML pages. Not separate controllers.
Well there are two potential reasons you might want to do this:

• Political, to somehow justify having two ways to implement the same thing
• Technical. Shortcomings of one technology prohibiting you from doing it

But neither of those stand. The political reason here should be irrelevant to you as a consumer of the ASP.NET MVC stack. More importantly however, the technical reason should not distort the reality.

So what should you do?

Personally I am against drawing this artificial non-existing line between the two concepts merely to justify technical shortcomings. The solution I would take is to have one API and use one of the two technologies, or if you’re open to alternatives, use those (OpenRasta, Nancy, FubuMVC), whatever,  I don’t care which one you use.

I have been using MVC for some years and the missing pieces such as content negotiation, HTTP authentication, ETag support (conditional requests), are nothing but a bunch of filters that are implemented with a few lines of code. Moving from operations to resources is nothing but a few routing techniques, implemented using some conventions (if you’re interested I have a lot of code I can share).

Whatever you do use though, don’t let its shortcoming dictate your design. You are implementing HTTP systems, embrace HTTP.

Now if you’re like me, a keyboard fanatic, you’ll probably say it is worthwhile, that it pays off in the long run, because the mouse, well it’s just not productive. In fact, the first thing I usually do when teaching a course on TDD or ReSharper is tell students to unplug the mouse. Why? Because the mouse just gets in the way. It makes you lose focus, it takes precious seconds away. Ultimately, the mouse breaks the flow.

Software developers and UI designers realized this as the graphical interface flourished. That is why the concept of keyboard shortcuts where introduced, to try and avoid menu and submenu navigation galore, specially on repetitive operations.

One size fits all fallacy

Keyboard shortcuts, easy to implement on desktop applications, were initially not so popular on the web. However, lately, it’s hard to find a decent web application (except that lame excuse for what Twitter calls an HTML application, a.k.a. the new Tweetdeck client) that do not have keyboard shortcut support.

And in principle, this might seem good. The problem however is that we have not only taken it too far, but we also seem to be committing the same mistake over and over again: trying to standardize behavior over devices and contexts.

Whether it’s the laziness of us, as developers, or the ambitious business orientated approach of re-use, we keep trying to apply same the thing in different places. We’ve seen the mistakes in hardware, such as trying to shrink Windows down to fit on a cigarette box (Windows Mobile), or the more recent approach of Microsoft, which is thinking that the Metro experience will be as pleasant on a desktop devices as it will on a touch-screen ones.

We’ve also seen this approach with software: think about all the different apps you are using that have Desktop and Mobile versions, where they try and offer the same experience. Does it always work? Why do we do it?

Forgetting the lazy developer or supposedly high ROI aspect, we also have this preconception that if a user learns how to use one interface, it will be easier. It maybe true, but I’d argue that if a user interface is simple and intuitive enough to not require a steep learning curve, it usually does not pose a problem. A homogenous design is not required to make things easier. It just means you’re used to the same errors.

Moving beyond devices and interfaces, we have the added misconception that all applications require the same type of interaction. It seems the general rule is that every application requires some icons and some keyboard shortcuts. That way, mouse-friendly-non-technical-savvy-users can be at ease with their pointing devices, be it a mouse, trackball or finger, and the hardcore users can be expert keyboard ninjas.  But not every type of interaction for every application has to be the same.

Commands: When shortcuts don’t make sense

If you’re old enough to experience buying a ticket at a travel agency, you’ll no doubt remember the agent whamming away at the keyboard trying to find a flight for you. Much like Scott mentions in his post, the airline industry still is a very keyboard heavy user-base. You hardly see any pointing devices lying around terminals at an airport. Many of these systems used commands, much like commands from the DOS or bash console:

• dir to list a directory
• mkdir to make a directory
• copy to copy a file

It worked well back then and it still works well today. A comment I left on Scott’s blog in reference to YouTrack which was listed there, was that although YouTrack has keyboard shortcuts, the main beauty of it is not having to remember these, but the ability to use commands. You see in YouTrack when you want to close a bug, you don’t have to remember a keyboard combination, you just start typing:

and as you type, YouTrack not only offers command completion, but also displays a list of recently applied commands. Once you type something coherent, it then tries to interpret your command:

It’s the same principle that was used in older systems, but brought up to date, to be less error-prone and more user-friendly. And of course, this works with any type of command, not only closing a bug.

Think about the interactions

A keyboard is not suitable for many scenarios. Imagine using a keyboard or using commands for drawing sketch diagrams or using AutoCad? We’ve been there, done that, and it wasn’t very nice. The ideal device for this type of interaction is a mouse or some other pointing device.

On the other hand, a keyboard is the perfect type of interaction for writing code, much like it is for writing a letter. Keyboard shortcuts are also great for these scenarios, where we do not want to lose focus.

Commands also have their place. When keyboards shortcuts are not viable, when focus is not about continous writing, yet we also do not want to be mouse-heavy, commands are a perfect fit.

What is important however to consider is that not all scenarios are equal. We seem to have somewhat learned this lesson by creating touch-specific applications, but we usually only take this into account when thinking about a device, more than thinking about the application. The actual purpose of the software is as important, in order to provide a productive and fluid user experience.

Even when the day comes where voice-controlled systems do improve, it won’t mean we need to apply it always.

One of the great joys of teaching, be it a class or giving a talk is this self-learning experience. Explaining something to someone else really helps in grasping that missing link you had; that uncertainty you weren’t sure about the first time you gave that talk. The “Ah, now I understand” moment you silently think to yourself while standing in front of your audience is very gratifying. This experience can be accomplished in many ways, such as authoring a book, writing an in-depth article or a blog post.

Although you learn as you teach, it doesn’t mean however that you can stand in front of an audience, and give a talk on a subject you’re not too familiar with, hoping to pick things up as you go along. You need to obtain that certain level of knowledge, reach that first milestone. It is a responsibility you owe not only to yourself, but also to your audience, to provide them with correct and ample information. A somewhat common joking remark is: “just make sure that you know more than everyone in the room”. Although amusing, it is a great incentive to push the limits, as it’s very hard to predicate whom your audience is, and what their background holds.

But it is important to understand that it is always a journey in which you teach but also learn. We are not born experts, whatever that term might mean.

With success comes responsibility

As we teach, we improve. As we improve we accomplish goals. These goals can be the respect of our audiences, the respect of our peers. We can start being labeled as experts around certain areas. This is encouraging and can lead to greater things. Being complimented on something we are passionate about, knowing we are succeeding is a great accomplishment, something we should be proud of. As we progress, we start to reach larger audiences. We start to embark on new areas, topics and interests.

Our prior success allows us and motivates us to embark on these new ventures. We have a faithful following. Our past experience shows that we are mostly correct in our teachings and this promotes more respect from our audiences. Our opinions are now taken as authoritative.

As this happens, we often lose sight of a fundamental thing that has made us reach this milestone in our journey: pushing ourselves in understanding things. Researching before teaching. Making sure we comprehend before explaining to others.

This is damaging. In the long run, it will lead to our own demise. The same respect we gained, we lose. But in the short time, and more importantly, we can deceive our audience. We can lead people the wrong way without us fully knowing what the right way is.

We now have a great responsibility and we need to act appropriately. Our status shouldn’t give us permission to take shortcuts, to skip milestones in our journey. We got here by building up the respect on our own merits. If we care about our audience, we should respect them back.

Skipping that first milestone openly

Not always do we have the chance or the desire to reach that first milestone before sharing our knowledge. Diverse reasons can warrant us to take a different approach when embarking on the journey of teaching. We can learn in the open. We can write about things and share that knowledge as we do our own investigation.

We should learn by asking questions. We should challenge what we learn, but do so with a proper understanding of what we are challenging. We should debate. We should be open to being proven wrong and most importantly we should learn to listen to others, much the same way we listen to our own voice, that same voice the improves our own understanding.

Arrogance won’t lead us to success, but it can lead us to failure.

Part I: Getting things set up
Part II: A premier on classes

A small but important note

Kotlin is still work in progress and not all design decisions are final. That is why your feedback is fundamental. So please provide any feedback via this blog, via our forums, via twitter on what you like, what you dislike.

Declaring variables

Before diving into classes, let’s first see how we can declare variables in Kotlin, as we’ll eventually need to do so when creating an instance of our class.
In Kotlin, variables can be declared in one of two ways, using the var or val keyword:

• var declares a variable that is mutable, that is, the value can change after it has been assigned

• val declares a variable that is immutable, that is, once assigned the value cannot change

Notice that we have not declared the type. Much like the var keyword in C#, since the variable has been initialized, the compiler can infer the type. However, if we do not initialize the variable, we need to explicitly define the type:

What happens however when we declare an immutable type that has not been initialized?

As expected, the compiler will allow us to set the value, but not change it. So all is good.

Knowing now the difference between val and var, let’s move on and look at classes.

Classes

Classes are the main building blocks for many object-orientated programming languages, and as such, of Kotlin also. An empty class declaration looks pretty much like that in C# and Java

(If you’re using IntelliJ, you will see items highlighted in the gutter with an icon and letter. In this case C represents Class)

Classes can be public, private, protected or internal. By default they are internal to modules (we’ll cover what modules and accessibility levels are later). This has the initial apparent disadvantage that you would not be able to test your code from outside a module. The team is currently working on a solution for this which would involve building modules in a specific way that would allow test projects to call internal classes. The approach however will not be the same as in C# where the attribute internalsVisibleTo is required.
To use a class, we merely create an instance of it. new keyword does not exist in Kotlin. A constructor call is similar to a function call.

Note that this customer has a default constructor that takes no parameters, which in Kotlin is a known as the primary constructor. We can override this primary constructor by defining a constructor as part of the class definition

with the actual implementation contained inside the anonymous initializer. This anonymous initializer is actually only necessary when we need certain logic. If we are merely using the constructor to initialize properties, we do not need it.

Now that we know how to create a class and define constructors, let’s add some contents to the class.

Properties

Usually classes in C# and Java are composed of fields, properties, methods and nested classes. In Kotlin, classes can contain properties, methods, nested classes and object declarations. We’ll cover this last one further along in the series. However, the key thing here to notice is that Kotlin does not allow fields. As such, everything is a property. It can be internal (default), private, protected or public.

Here we have one internal property and two public ones. Notice how the internal one does not have an explicit type declaration. It is not needed. However, if we were to remove the type declaration for one of the public properties, we’d get a compiler error

The reason for this is to prevent unintentional breakage of a public API, since it’s much more likely to change the type of a property without realizing the impact it might have if it’s not explicit. Another thing to notice is that all properties require explicit initialization, irrelevant of their accessibility or whether they are mutable (var) or immutable (val).

Was that an AutoProperty?

If you’re a C# developer you’re no doubt familiar with the autoproperties, whereby the compiler internally has a backing field holding the value of a property, without requiring you to define explicit getters and setters unless you want to define explicit behavior. Kotlin is pretty much the same in that way and what we just saw uses an internal backing field which is called the same as the property but prefixed with the character $

Custom Getters and Setters

What happens when we want to provide custom behavior when reading or writing to properties? In these cases we can define getters and setters

This is an example of a customer getter which always returns “Always Jack” as the value of the property Name irrelevant of what value it has. Notice how we just define it below the property. If our getter requires more than one line, we can use a { } block.
Much like the getter, we can also define a setter. In this setter, we can write any logic that interacts with other properties of the class. But what happens when we want to interact with the actual backing field of this property (the one that the compiler creates automatically)? as mentioned before, we can use the $ prefix to access it

Setters can have different accessibility levels, by prefixing them with the corresponding keyword.

Functions

Although we won’t dive too deeply into all the different aspects of functions in this part (otherwise it would be too long of a blog post), we will see the basics to create functions as part of our classes. A function declaration, in its simplest form is:

consisting of the function name, optional parameters, optional return type and the body. Functions in Kotlin return tuples, that is they can return more than one value. When we do not specify a return type, we are implicitly saying that the return type is a Unit which is a tuple with 0 components.
Below is a full example of a class that takes two parameters in the constructor, initializes some properties and contains a function the prints out the full name.

We’ll dive deeper into functions and all the possibilities they offer in a different post.

Summary

In this second part, we’ve covered the basics of classes, how to declare one, how constructors work and how to define properties and functions. Classes in Kotlin however offer much more and there’s a lot more to learn about them. In other parts we’ll cover the difference between open and final classes (hint: default is final), abstract classes, inheritance, as well as traits, which are somewhat similar to interfaces in C#.