PHP in Action

I got some interesting comments to my previous post on "beautiful code". Some were pretty strong disagreements.

So am I wrong? Did I get carried away? Did my critical faculty go on vacation somewhere nice and sunny? I admit that sometimes I deliberately look at the positive and ignore the negative. (And sometimes I do the opposite; It's a good exercise if you're careful.)

I wasn't drunk, anyway. But let me take a closer look at the particular line of code I was praising:

$this->assertThat($form->hasSelect(withName('statusConfirm'))->hasValues(),
    array('Yes','No'));
 

My main point is that it's close to plain English. Not everyone agrees that that's a good thing, but I argue that we're built (genetically wired, in fact) to understand natural languages, not program code. Therefore code should be easier to understand when it approximates natural language and expression. And we're trying to create or approximate a Domain Specific Language (DSL), which should express exactly what's required for the domain and not the demands of the technical implementation.

So for this experiment, let's translate this one into a (plain English sentence:

Assert that Form (this particular one) has a select menu with the name "statusConfirm" and values "yes" and "no"

Translating back into code, it might look more like this:

$this->assertThat($form)->hasSelect()->withName('statusConfirm')->andValues('yes','no');
 

To me, this is even more natural than the other one. I think we've gotten rid of some syntax that has to do with implementation details rather than making the API simple to use.

It also seems clear to me how this could be implemented. All of the method calls could be to an assertion object that would take all these various inputs and always return itself at the end of the method so you can chain the calls in what's known as a fluent interface.

Max Horwath has published his slides on Making Selenium Test Writing easier using a DSL onlinefrom IPC 2008. Let me quote the whole short description:

Implementing automated tests by using Seleniums API methods has several drawbacks. Selenium is great for what it does, providing a generic framework for testing a generic application. Using the Testing_SeleniumDSL framework, I will show you how to create your own Domain Specific Language (DSL), which would allow you to write tests in the language of your business rather than in Seleniums language.

I'm quite impressed by the examples he presents, such as:

$this->assertThat($form->hasSelect(withName('statusConfirm'))->hasValues(),
    array('Yes','No'));
 

This is truly expressive, readable code. I've refactored web test code in this direction many times, but I admit I never got quite this far.

The DSL is planned as an open source release. It would be interesting to try something similar for the SimpleTest web tester, which is my favorite for testing web interfaces without too much JavaScript. (Based on the paparrazzi principle.)

Refactoring is by definition a design actitivity, since the definition of refactoring is "improving the design of existing code". But is this generally and fully recognized? After attending my friendly local agile conference (Smidig2008—sorry, it's in Norwegian), I'm getting more of a feel for how different people think about it. And I'm wondering whether the use of metaphors such as "cleaning" makes refactoring seem too much like unskilled labor. After all, physical cleaning jobs are seen that way.

The analogy between cleaning and refactoring is useful for making the non-developers understand that refactoring is absolutely necessary. But beyond this pragmatic similarity, are the two really similar in deep and meaningful ways? I don't think so. Refactoring is not unskilled labor. It's a task that both requires and builds design skill and experience. While anyone can see that a floor is dirty, identifying code smells is non-obvious, tricky and demanding. This is true even of the simplest code smell, duplicated code. Although spotting code duplication is sometimes easy, at other times, the duplication is too subtle to be easily identifable. When you clean a floor, the goal is well-defined and easy to visualize. When refactoring, you may know what you're aiming for at each small step, but just a few moves further ahead you may end up with a structure you hadn't imagined.

There's a tutorial that appeared recently called Get Links With DOM. Planet PHP lists the author as Kevin Waterson, although his name is not mentioned on the page itself. Anyway, he claims:

Perhaps the biggest mistake people make when trying to get URLs or link text from a web page is trying to do it using regular expressions. The job can be done with regular expressions, however, there is a high overhead in having preg loop over the entire document many times. The correct way, and the faster, and infinitely cooler ways is to use DOM.

Yes, of course it's cooler. But I'm a little bit surprised at the claim that it's the "correct" (only) way, since there's at least one more that I find even cooler: XPath. Admittedly, it's slower, yet it's a more powerful language.

In his example, we just need to add a line to create an XPath object after we've created the DOM object:

$xpath = new DOMXpath($dom);
 

Then, instead of the DOM call:

/*** get the links from the HTML ***/
$links = $dom->getElementsByTagName('a');
 

we can use an XPath query:

/*** get the links from the HTML ***/
$links = $xpath->query('//a');
 

That's all. So why is that cooler? Because you can do more powerful searches easily. The DOM just happens to have a simple call to find all elements with a certain tag name, so there's not much difference in this case. But more complex stuff is something else. For instance, we can get just the URLs with a single expression:

$links = $xpath->query('//a/@href');
 

Or we can get just the URLs of just the links whose CSS class is "bookmark":

$links = $xpath->query("//a[@class='bookmark']/@href");
 

I've been using this for ages when testing web pages. Then there's the not quite official SimpleTest DOM tester, which uses CSS selectors to specify paths. But I won't go into that right now.

This is something I posted to the Sitepoint PHP Application Design Forum with a little bit of added background.

The background is the idea that unit test methods, for the sake of readability, should test only one single behavior. This may mean several tests for one method under test, since one method may have several behaviors. One version of this is the notion of one assertion per test.

Web tests are not quite the same thing as unit test. On the Sitepoint forum, in a discussion on web testing, I said:

It's also very slow to have too many separate test methods. So instead, to make it readable, I tend to use custom assertions.

Marcus Baker asked me for examples. I tried to illustrate the principle with an example that may be a something of a caricature.

If performance and speed were not an issue, I might do something like this, keeping each test method short and sweet: PHP Code:

class ArticleListTest extends WebTestCase {
 
    function setUp() {
        // Some code to log in and go to the article list page
        //....
    }
 
    function testHttpStatusOk() {
        //...
    }
 
    function testHasCorrectTitle() {
        //...
    }
 
    function testHasNoDebugInfoAccidentallyLeftBehind() {
        //...
    }
} 
 

Unfortunately, it would be nauseatingly slow, since you have to traverse some web pages for every single test method. Instead, I can try to get similar small chunking by using custom assertions: PHP Code:

class VariousPageTests extends WebTestCase {
 
    function testLoginAndArticleList() {
        // Some code to log in
        //....
 
        $this->assertStartPage();
 
        // Some code to go to article list page
        //....
 
        $this->assertArticleListPage();
    }
 
    function assertArticleListPage() {
        $this->assertHttpStatusOk();
        $this->assertHasCorrectTitle();
        $this->assertHasNoDebugInfoAccidentallyLeftBehind();
    }
 
    function assertStartPage() {
        //
    }
} 
 

This way, the code has names for approximately the same details as in the first example.

Max Horvath has implemented a library for type hinting scalars. That interests me, since I find that type hinting for objects has limited usefulness.

I tried using type hints extensively from an early beta version of PHP 5. I mostly gave up on them for three reasons:

1. They make refactoring harder since you get lots of dependecies on a particular class name.
2. Making sure an object is the right class has limited usefulness. If you pass an object of the wrong class to a method without type hinting, you're still alerted to the error the moment you try to call a non-existent method (one belonging to the class it was supposed to be as opposed to the class it actually is). This typically happens early.
3. My experience is I hardly ever see actual bugs in practice that would have been caught earlier if there had been a type hint. I (nearly) always have good unit test coverage. It may be different if you don't, but that's not an advisable way to live.

I admit that these jugdments are hard to make. I could be wrong, more or less. Type hints are probably useful when code becomes stable enough and at the boundaries between modules. But I still tend to avoid using them until I get an actual bug that might have been prevented by a type hint. Their usefulness is and has to be an empirical question. The purpose of using them has to be catching errors earlier, so if they don't have that effect, there's no point.

For the purposes of this blog post, reason 2 is the important one. The idea is that type hints are more useful for arrays and scalars than for objects. Why? Because they have the potential to catch errors that would otherwise be hard to find or escape unnoticesd. As I said, if you pass an object of the wrong class, you will usually get a "non-existent method" error quickly. The same thing happens if you try to pass an array or scalar instead of an object. But if you try to pass an object instead of an array, an array instead of a scalar or vice versa, you can keep using the passed array or scalar for some time before it blows up. The problem becomes harder to track down. I've used type hints for arrays, and found them more meaningful and less troublesome than object type hints.

One case I've seen in which scalar type hinting would be useful is a simple homegrown date and time object that is initialized by passing a Unix timestamp as an argument to the constructor. A couple of times I've made the mistake of passing an object instead. The ensuing error can be hard to figure out. If I could type hint to make sure it's an integer, that would be helpful.

I like weird ideas. There should be more of them. And the idea that we need to make programs efficient to save energy is weird enough to interest me.

David Peterson tells his version of Rasmus Lerdorfs views on it:

He continues on by stating that PHP developers really need to think about performance for not only scalability reasons but for green reasons. If programs were more efficient it would cut the number of data centres and would reduce energy needs as a result. In our newly emerging age of energy awareness this does become an important aspect and I am glad that he is raising awareness.

Well, theoretically, using less of anything makes good environmental sense. But you have to consider which actions have a big impact and which are marginal. For example, Norwegian politicians have considered banning incandescent light bulbs. But the idea makes a lot less sense here than in some other countries, since it's hardly ever dark and warm at the same time this far north. Therefore, the heat generated by indoor lighting contributes to heating that would be needed anyway and is usually electric already.

"Premature optimization is the root of all evil." It occurs to me that energy saving is a kind of optimization and subject to similar considerations. It needs to be focused so it's applied where it matters most and where you can get the most out of the least effort.

How much traffic does a web app need to have to make optimization worthwhile? Does the green angle add anything to that assessment?

Theoretically, it might if the cost of energy does not cover the cost of its environmental consequences. But it's a question that requires analysis. If cutting data center energy consumption is important, it makes sense to know and apply the strategies that are most cost-effective. Putting the waste heat to use? Using more of the hardware and techniques that are used to make laptops energy-efficient? I don't know, I'm not an expert on these things. What I do know is the idea of green optimization needs that kind of thinking to put it in context.

I came across a Zend Framework (ZF) example I wanted to refactor. You really have to have unit test coverage to refactor effectively, and since there were no tests, I started trying to find out how to test it. There didn't seem to be a wealth of information available on the web, so I've tried to figure it out by myself.

Several challenges presented themselves. It might seem as if the ZF controller system is not optimally designed for testing action controllers, but there are always ways to get around obstacles.

A ZF action controller (which is really just a group of actions collected in a class) always extends Zend_Controller_Action. (For an introduction, see the official QuickStart).

The one I was playing with was an authentication controller:

class AuthController extends Zend_Controller_Action...
 

That's all we need to know about the specific class under test for now.

I always like to set up the basic objects for the test as instance variables in the setUp() method, so that I can write many small test methods exercising them in various ways. To even get started testing an action controller, we need to instantiate it outside its usual environment, the Zend Front Controller. It requires a request object and a response object:

class AuthControllerTest extends UnitTestCase {
 
  function setUp() {
    $this->request = new Zend_Controller_Request_Http();
    $this->response = new Zend_Controller_Response_Cli();
    $this->controller = new AuthController($this->request,$this->response);
  }
 

(I'm using SimpleTest here, but the same techniques should apply to PHPUnit with different syntax.)

The challenge increases increase when we want to use View Helpers, such as the flash messenger. When programming the action controller, it looks like this:

$flashMessenger = $this->_helper->FlashMessenger;
 

To test this meaningfully, we need to replace the flash messenger with a mock object. That means also having to replace $this->_helper, which is a "helper broker" object.

First, we generate the mock classes:

Mock::generate('Zend_Controller_Action_HelperBroker','MockHelperBroker');
Mock::generate('Zend_Controller_Action_Helper_FlashMessenger','MockFlashMessenger');
 

Unfortunately, the helper broker is a protected instance variable, with no apparent way to change it. But it's easy to fix by adding a setter method to the action controller class:

class AuthController extends Zend_Controller_Action...
 
  public function setHelperBroker($helperBroker) {
    $this->_helper = $helperBroker;
  }
 

This allows us to set up the mock helper broker and let it return the flash messenger:

$this->helperBroker = new MockHelperBroker;
$this->controller->setHelperBroker($this->helperBroker);
 
$this->flashMessenger = new MockFlashMessenger;
$this->helperBroker->setReturnValue(
  '__get',$this->flashMessenger,array('FlashMessenger'));
 

Now we can use the mock objects to test an action which is supposed to send a flash message:

function testIdentifyActionSendsFlashMessage() {
    $this->flashMessenger->expectOnce(
        'addMessage',
        array('Please provide a username and password.'));
    $this->controller->identifyAction();
}
 

That's as far as I'm going with this now. There may be more later.

Redirects are useful in web programming, especially when implementing the Post-Redrect-Get pattern. But there is a problem with redirects: there is no simple way to send a message to the user across the redirect. When processing a GET request, you can display whatever messages you want. The most simplistic way is to echo them directly; or if just slightly more sophisticated, set it in the template that's about to become the web page. When processing a POST request that is to be followed by a redirect, you can't do that. The response (redirect) sent back to the browser does not have any text or HTML content. In practice, it just contains the URL of the page you're redirecting to. If you try echoing the message, it will cause the redirect to fail because you sent content before the header that signals redirect.

So how to get the message displayed? The simplest way to do it would be to include it in the URL:

header('Location: http://www.example.com/index.php?message='.urlencode($message));
 

It's possible, but your URLs can get very long and you might find it silly:

http://www.example.com/index.php?message=This+is+a+message+to+demonstrate+how+long+a+URL+can+get+when+you+put+long+strings+into+it

The more common choice is to keep the message in session and make sure it's removed from session after it's been displayed. That's what flash messages do. In military terminology, a flash message is defined as:

A category of precedence reserved for initial enemy contact messages or operational combat messages of extreme urgency.

I don't like a name that could be confused with Adobe Flash, so when I implemented my version of this, I looked up "flash" in the thesaurus and decided to call them flares instead.

Here are a couple of examples I've picked up.

Zend Framework:

$flashMessenger = $this->_helper->FlashMessenger;
$flashMessenger->setNamespace('actionErrors');
$flashMessenger->addMessage($message);
 

CakePHP (from http://labs.iamkoa.net/2008/01/13/session-based-flash-messages-look-better-cakephp/):

$this->Session->setFlash('Your post has been saved.');
$this->redirect('/news/index');
 

In my own work, I've done it in a slightly different way by letting the redirect object hande the flash/flare and returning the redirect object from the action method, somewhat like this:

return Redirect::toAction('settings')->addFlare('Settings changed');
 

I don't necessarily claim that it's better than the others, but it makes sense to have alternatives.

This article was originally posted with an incorrect timestamp, and has been updated to the current time as of June 2.

Silvan Mühlemann has written an excellent piece titled Unit testing makes coding more fun.

I keep saying that sort of thing, too. I also say it raises your IQ. But when I attended a presentation by Uncle Bob (Robert C. Martin) last summer, I was mildly shocked to see that he described TDD as tedious (but a requirement for professionalism). I confronted him politely about it, emphasizing that above all I find TDD relaxing. Why? Because bugs bug me. I get stressed when I have to search for a bug and even more so when it takes much longer than expected (I'm sure that never happens to you). With TDD, bugs are always small and easy to locate.

Uncle Bob seemed to agree with me as far as his own experience was concerned, but he believed that many developers found the non-TDD process exciting rather than stressful.

Sounds weird to me. But I know from long experience that sometimes people are different from me in ways that make reality seem stranger than fiction.

I want Enums in PHP

I'm currently working about equally in PHP and Java. I can't say I've fallen in love with Java. But Java does have a feature or two that would be useful in PHP. One of them is the Enum (enumeration, that is), which is traditional in some languages and DBMSes (including MySQL) and was introduced in Java 1.5 (or is that 5.0? I'm sure they do that just to expose people like me as Java amateurs).

Enumerations are useful when a variable can have one of a given number of values. Actually useful examples I've encountered in web programming are states or stages in a process and user roles. Another kind of example is one I used in PHP In Action: an authorization system with three fixed roles or categories of user: regular, webmaster and administrator.

If we represent the roles as text strings, we risk getting our tests wrong:

if ($role == 'amdinistrator')...
 

The only problem is that the word “administrator” is misspelled, so the test won't work.

This can be solve by representing the values with named constanst instead. Using class constants in PHP 5:

class Role
    const REGULAR = 1;
    const WEBMASTER = 2;
    const ADMINISTRATOR = 3;
    ...
 

Now we can do this instead:

We won't get away with any misspellings here; using an undefined class constant is a fatal error. Compared to global constants, this may be easier to figure out, not least because we know where the constant is defined (inside the Role class) just by looking at it.

This is called the int Enum pattern in the official description of Java Enums. The documentation also lists some problems with this, starting with type safety, which we're not that concerned with in PHP anyway. A more relevant problem is the fact that when you print the value, you just get the number.

But I don't see why you shouldn't use strings for the values:

class Role
    const REGULAR = 'REGULAR';
    const WEBMASTER = 'WEBMASTER';
    const ADMINISTRATOR = 'ADMINISTRATOR';
    ...
 

One PHP-specific problem I didn't mention in the book is the problem that happens with long class names. Since we still don't officially have namespaces in PHP, we will easily end up with nauseatingly long constant names, like this:

It's quite depressing to have to do that a lot. I've tried putting constants in their own class with a shorter name, but I didn't like it much. One thing I tried recently was creating instance methods to return the constant value:

class MyProject_Authorization_RBAC_Role...
    public function REGULAR { return self::REGULAR }
    public function WEBMASTER { return self::WEBMASTER }
    public function ADMINISTRATOR { return self::ADMINISTRATOR }
 

Now we can create an instance with a short name and get the values from that:

$roles = new MyProject_Authorization_RBAC_Role;
if ($role == $roles->ADMINISTRATOR())...
 

All of this just to get shorter names? I little desperate perhaps. So yes, I would like Enums in PHP.

Everybody who writes object-oriented code knows about constructors. You need them so the program knows how to instantiate objects, right? And you especially need them when a lot of things have to be done while instantiating an object. And personally, I've never considered visibility restrictions important enough to be a major argument against those languages that have lacked them (PHP 4). So why would I be skeptical of public constructors?

I got the idea after reading Joshua Kerievsky's book Refactoring to Patterns. One of his refactorings is called Replace Constructors with Creation Methods. In Java, unlike PHP, you can have multiple constructors that are distinguished only by the number and type of arguments. That may be practical sometimes, but as Kerievsky's example shows, it be more readable to have creation methods with different names instead. Which is what you have to anyway in PHP.

But why not take this one step further and do it even when there is only one constructor? For example, here's an ultra-basic Redirect class:

class Redirect {
    private $url;
 
    public function __construct($url) {
        $this->url = $url;
    }
 
    public function execute() {
        header("Location: ".$this->url);
        exit;
    }
}
 

This may seem simplistic, but it is the kind of class I might actually use at an early stage in the development of a web application. Anyway, we can apply what is essentially the same process as Kerievsky's by adding a creation method whose name is somewhat more telling than __construct().

class Redirect {
    private $url;
 
    public function __construct($url) {
        $this->url = $url;
    }
 
    public static function withUrl($url) {
        return new self($url);
    }
 
    public function execute() {
        header("Location: ".$this->url);
        exit;
    }
}
 

Now all that remains is to make the constructor private.

    private function __construct($url) {
        $this->url = $url;
    }
 

Is this an improvement? The additional code might be considered unnecessary complexity, or in a word: clutter. On the other hand, our client code might seem more readable when it looks like this:

    $redirect = Redirect::withUrl("http://www.example.com/index.php");
    $redirect->execute();
 

Instead of:

    $redirect = new Redirect("http://www.example.com/index.php");
    $redirect->execute();
 

You could object that it's fairly obvious anyway in this example that we're inputting a URL. But if the URL string is supplied as a variable or method call instead of a plain string, it would be less obvious.

No doubt there are many cases in which a plain constructor is the best choice, but I think this is worth considering.

As if to remind us that not everyone in Ruby hates PHP and vice versa, Rails creator David Heinemeier Hansson commends the immediacy of PHP.

I'm vaguely wondering if he's also understood the potential of the smooth, agile ride from the immediate to the complex. Probably not.

To quote myself from the Sitepoint PHP Application Design forum, to the question When do you think it is time to develop a custom framework?, I answered:

Never. Always. Start dirt simple and refactor to eliminate duplication. When you need a specific feature, study how it's done in existing frameworks and implement it. That will get you a "framework" that has exactly what you need.

This is an approach that is facilitated by the immediacy of PHP. Is this approach slower, long-term, than adopting a framework? That probably depends on a lot of variables. If an existing framework does everything your application
needs, it may be a great idea to use it. On the other hand, if you need to do things that are significantly different from what the framework supports, you need to start mucking about with the framework itself. In that case, it may be more
effective to have you own "framework" that fits the application like a glove, without a lot of features you will never need, and without features that are almost, but not quite what you need.

I love Ruby, but I've never actually tried Rails. Reading Rails tutorials, I'm not quite as impressed as some folks I know.  Rails certainly represents the state of the art in web programming. So do the leading PHP frameworks, some of which are heavily inspired by Rails.  The difference is not that striking. But I don't want the state of the art, I want the web framework of the future. And can that be built on the existing frameworks, or do we need to start from scratch? There are some interesting possible beginnings out there, such as Phaux.

I follow the principle that you should test everything that could possibly fail. And I would like to have unit tests for everything; tests that exercise each small behavior in isolation. The components that are easiest to unit test are typically class and methods in plain object-oriented code. Not everything falls into that category, though. Page templates, XSLT and other XML files are some counterexamples.

As I mentioned in my blog post on Paparrazzi testing, Uncle Bob (Robert C. Martin) has discussed how to test web templates or server pages. Since I'm currently working with Smarty templates, I wanted a simple way to run tests on them without needing to deal with a web server and the page navigation in a full web application.

Simpletest's web tester has a simplified web browser that's capable of running HTTP requests to test an actual running web application. To test a Smarty template in isolation, we can replace it with something even simpler that talks directly to the Smarty  template engine instead of the web server. It's this simple:

class SmartyBrowser {
    private $smarty;
    private $template;

    function __construct($smarty,$template) {
        $this->smarty = $smarty;
        $this->template = $template;
    }

    function getContent() {
        return $this->smarty->fetch($this->template);
    }
}

getContent() can replace the getContent() method of Simpletest's built-in browser (SimpleBrowser), enabling SimpleTest to run all the usual assertions on the generated HTML page. To make this happen we replace the SimpleBrowser instance with the SmartyBrowser:

<?php
class SomeTemplateTest extends UnitTestCase {
    function setUp() {
        $this->smarty = new Smarty;
        $this->_browser = new SmartyBrowser($smarty,'page.tpl');
    }

Also, we need the usual Smarty directory setup.

Now we can test Smarty output. What would be really interesting, but much more complex, would be to extend the concept to actually testing two-way interaction between the server / template and the client / browser.

 

Uncle Bob (Robert C. Martin) has blogged about testing GUIs (web interfaces, that is; JSP and Rails) without having to run a web server. I don't think it answers all the challenges I'm up against currently, but it inspired me to some heavy thinking about the essential issue of complete and not too cumbersome test covrerage

My conclusion so far is that Uncle Bob's articles is an example of what we may call the paparazzi principle.

Paparazzi try get as close as possible to celebrities they prey upon. The fewer walls or windows between the camera and the victim, the better. Pictures should be as revealing as possible; naked is or half-naked is good.

The paparrazzi principle for web testing is this: run the test from “above” as close as possible to the component you want to test. Inject mock objects from “below” as close as possible to the component you want to test. Even in ordinary unit testing, this can be far from trivial. Where the web interface itself is involved, it is much harder.

It follows that you don't want to use a real web browser or web server unless you must. It also follows that a realtively simplistic web client (SimpleTest's web browser is a good example) without a user interface is preferable to a web browser for human use. Unless you absolutely need it, that is. Therefore, Selenium is probably a step in the wrong direction. I want test tools that enable me to test user interaction without having to fire up these voluminous masses of software.

Get the book now from Manning

• Main
• Archives

«	November 2008					»
Su	Mo	Tu	We	Th	Fr	Sa
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30

• More beautiful code
• Beautiful code
• Refactoring is design
• Get links with XPath
• Many test methods versus custom assertions
• Type hints are more useful for scalars than objects
• Performance optimism
• Testing a Zend Framework action controller with View Helpers
• Flash messages
• The psychology of test-driven development

• Application design [15]
• Testing [11]
• PHP [22]
• Refactoring [2]
• Ruby [3]
• Smidig2008 [1]
• Java [1]
• General [0]
• Frameworks [2]
• CSS [0]
• JavaScript/Ajax [0]
• Me [4]
• Vim [1]
• Humor [0]

• RSS 0.90
• RSS 1.0
• RSS 2.0
• Atom