http://jamieonsoftware.com Development, entrepreneurship and rude remarks. en-GB jamie@jamierumbelow.net Copyright 2010 2010-06-09T10:26:03+00:00 http://jamieonsoftware.com/blog/entry/eeci-wrap-up http://jamieonsoftware.com/blog/entry/eeci-wrap-up#When:11:26:03Z I’ve been collecting all the photos, videos, slides and more from my recent trip to San Francisco and the ExpressionEngine CodeIgniter Conference. There’s still plenty more reports, photos, videos et cetera appearing all over the internet, so if you’re interested keep checking back and I’ll update this post with other’s wrap-ups, as I’m sure there’ll be many. If you missed it, the second ExpressionEngine CodeIgniter conference was held from May 31st - June 2nd in the Fort Mason Centre in San Francisco, California, United States of America. Robert, Janneke, Chris and the rest of the Whoooz! team really pulled out the stops, and ran a fantastic conference. The Venue and San Francisco I was thrilled to get to visit San Francisco. The city is incredible, the culture fantastic and the vibe, pure electric. There’s every race, religion, sexuality and gender under the sun, everything’s so liberal and open. I’ve rarely had so much energy, so much passion. It was an inspiring location, and a perfect place to hold a technical conference. The venue itself, the Fort Mason Centre, was pretty interesting. While the rooms weren’t exactly perfect, it was a gorgeous location, and turned out to be a great venue. There were plenty of facilities on site, and I managed to have my first ever root beer. Let me tell you now, children. Root beer is incredible. It’s so damn good, I can’t believe we don’t have it in the UK. Anyway, I digress. There was a lovely vegetarian restaurant that I got to try out called Green’s, so thanks a lot to Mitchell Kimbrough at Solspace for taking me there. Community I’ll speak for every CodeIgniter attendee at the conference: being able to interact with and talk to our ExpressionEngine counterparts was an absolute pleasure. Attending EECI is a huge reminder of just how awesome both communities are. While I wasn’t allowed in either of the after parties for obvious reasons, I was allowed in Kennedy’s Bar where many social events took place, and mingling with the ExpressionEngine and CodeIgniter folk was just fantastic. Adding to an open bar, I’m sure it’d be brilliant. During the conference itself, there was plenty of interaction. There was no barrier between speakers and attendees: just passionate people geeking out about their favourite framework and CMS. The Solspace CodeShare Corner was a great place to chat to people or show off new projects. Relationships were made, deals were cut, and I’m sure there’ll be plenty of interesting projects that spew out from this conference. Sessions All the sessions were stellar. Boasting an incredible mix of great speakers, on a variety of topics, EECI really was an inspirational and informative conference. Many conferences nowadays are only good for the social networking, but EECI was definitely an exception. I don’t think I’ve ever heard the word ‘ExpressionEngine’ more times in a single day than I did on June 1st. While everyone was fantastic, I’d like to show my appreciation to Ed Finkler, Tom Myer, Simon Collison, Brandon Kelly and Kenny Meyers, who all put on brilliant presentations. I also hear fantastic things about Jamie Pittock’s, Leslie Flinger’s and Greg Wood’s sessions, so be sure to check them out. You can find the videos from the sessions online if you buy a online pass, and it’s highly recommended. MojoMotor and Community Partners Damn near everyone from EllisLab were present at the event, and Rick Ellis, Leslie Camacho, Derek Jones and Derek Allard gave the keynote. Leslie announced that EllisLab were opening up a new program called Official Community Partners, which provides support, financial backing and official status to community sites. Currently, these are all EE-focused, but I don’t doubt that CodeIgniter focused community sites will start to pop up. Derek Allard, EllisLab’s technology architect announced EllisLab’s next product, MojoMotor. MojoMotor is a small CMS designed to “do less”. MojoMotor is currently in private BETA, but it’s going to be opened up to the public very soon, and let me tell you, it’s something special. Keep an eye on this one. My Presentation My presentation was titled “Getting Ignited with EE2”, and was all about how to get into ExpressionEngine add-on development from a CodeIgniter perspective. My talk went down really well, with loads of people tweeting and congratulating me for it. It was a really fun subject to talk about, and managed to appeal to a wide range of people; loads of people from both the CI side and EE side turned up to my talk. Get the slides at SlideShare and the ending video over at Vimeo. EECI 2010 EECI 2010 was an absolutely brilliant conference. I loved every minute of it, and I’ll definitely recommend heading over to Leiden in September for EECI Europe. Mega props to everyone who attended, the guys and girls at Whoooz!, all the speakers and everyone else involved with the ExpressionEngine-CodeIgniter event of the year. 2010-06-09T11:26:03+00:00 http://jamieonsoftware.com/blog/entry/coming-up-at-eeci-2010 http://jamieonsoftware.com/blog/entry/coming-up-at-eeci-2010#When:13:48:26Z There are going to be loads of people at EECI2010 SF, but the majority of them are going to be ExpressionEngine folk. We need to get the CodeIgniter numbers up, people, so I thought I’d post a sneak preview of my talk and my masterclass. If you want to get tickets already, head straight over to the EECI website and get them ASAP! Kicking arse with EE2 EE2 is written on CodeIgniter. That gives us, CodeIgniter developers, the perfect chance to get into a market, the perfect chance to merge the communities, and moreover, the perfect chance to kick some serious arse. How do you get started with EE2 development? How do you sell your add-ons? What common pitfalls and problems do EE developers come across? All this and more, in this funny, real, and occasionally controversial talk from the CodeIgniter Community Chieftain, Jamie Rumbelow. MongoDB and CodeIgniter Everyone’s talking about MongoDB. It’s a brand new, scalable, fast and lightweight document-oriented database that is totally different from any relational databases like MySQL or PostgreSQL. But what makes it so special? And more importantly, how do you use MongoDB in your CodeIgniter applications? Find out what Mongo is, how to install it and why it’s so awesome in this MasterClass from the CodeIgniter Community Chieftain, Jamie Rumbelow. 2010-05-13T13:48:26+00:00 http://jamieonsoftware.com/blog/entry/terrible-wording-on-an-advert http://jamieonsoftware.com/blog/entry/terrible-wording-on-an-advert#When:16:55:30Z Here’s some extremely bad wording on an advert I saw in Tweetie: This is essentially saying ‘Our product is really complex and hard to use, why don’t you give it a go!’ Clearly the copy writer didn’t read it when they saw it, because this jumps out as an overwhelmingly bad mistake in copy writing. Alternative methods of phrasing might be ‘[Brand Name] is the most powerful, feature rich system utility available. Give it a try now!’, or ‘[Brand Name] solves some of your most complex system utility problems for you.’ Make your product work for your users, not against. Additionally, make this apparent to potential customers in your advertising. First impressions count. 2010-05-08T16:55:30+00:00 http://jamieonsoftware.com/blog/entry/forking-codeigniter-on-bitbucket http://jamieonsoftware.com/blog/entry/forking-codeigniter-on-bitbucket#When:18:56:20Z CodeIgniter 2 is available (in development) on BitBucket, and because of that, it’s ready for you to fork and work on. The EllisLab people are usually pretty good with answering pull requests and feature additions, and the most likely way of them accepting any proposals is for you to dive in and get coding. I thought I’d put together a quick guide on forking CodeIgniter. How? It’s easy. Visit the CodeIgniter BitBucket Page and hit the “Fork” link. It’ll guide you through forking it, and will eventually redirect you to your forked repo’s page. Copy the HTTPS/SSH link there (pick your choosing; I prefer SSH but need to use HTTPS for some stuff because my school blocks port 20… plus, if you’re running windows then setting up SSH can be tricky). Jump into terminal and navigate to the directory in which you want to store your fork. Getting to know hgrc We’ll start off by cloning the directory from the remote repository, using that URL we got a minute ago. hg clone ssh://hg@bitbucket.org/jamierumbelow/codeigniter This will bring all the files from the remote repository and download them locally. cd into that directory. Now, we want to be able to pull in updates from EllisLab and merge them with our updates. Luckily, using Mercurial this is a piece of cake. Mercurial stores all the repository information in one root folder called .hg. It looks for a file called .hgrc in there to set repository-level settings. Open up the .hg/hgrc file in your text editor (in my case, TextMate). mate .hg/hgrc You should already see a few lines in here. It should look something like this: [paths] default = ssh://hg@bitbucket.org/jamierumbelow/codeigniter This is setting the default path to be your repository. This means that by default, hg push and hg pull will use that URL to push and pull changesets from. We want to add a new path that links back to EllisLab’s copy of CodeIgniter, so we can pull changes from them. Underneath the default path declaration, add the following: ellislab = ssh://hg@bitbucket.org/ellislab/codeigniter And that’s it. Now, save that file and jump back into Terminal. We can now pull changesets from EllisLab by running hg pull ellislab. Great! We can make our own changes, commit them and push them to our own repository. Then, all you have to do is hit “Pull Request” in BitBucket and your changes will be speeding off to EllisLab instantly. That wasn’t so hard, was it? 2010-05-04T18:56:20+00:00 http://jamieonsoftware.com/blog/entry/rumbel-oh-the-joker http://jamieonsoftware.com/blog/entry/rumbel-oh-the-joker#When:08:15:52Z I’m extremely annoyed with myself. Let this be a lesson to everyone who is working on a project and has put anything more than 2 hours work into it: Back up and use some form of version control. If you don’t, you’ll seriously regret it. Anyway, let me tell you a story… Welcome to Expressionland A long time ago there existed a country which called itself Expressionland. It was a reasonably happy place; it’s monarch, the Emperor Ellis was kind to its people, the lords and ladies were generous and there was always an opportunity for anyone to profit within the gates of its capitol city. The Emperor Ellis held a number of mechanical devices, which we would know as engines. Each time a problem occurred with the engines, or the Emperor needed them to go faster or for longer, the Chief of the Guards, Sir Jones, would call upon his minions and the people of Expressionland to assist him in upgrading the engines. Sir Jones, who was a kind man, made the upgrade process as simple as possible; merely replacing a few parts of the engine while keeping the main cogs intact. Very rarely did anyone run into any issues, and when they did, Lady Lisa, the kingdom’s most respected inhabitant, would be there on call to assist anyone. For years people lived, undisturbed in Expressionland. The residents of this wonderful place were happy. There’s always a Joker Stumbling up to the city gates, a Joker, by the name of Rumbel-oh!, and with a passion for mechanics, asked if he could join the city. He thought he could bring a new spin to the engines, and the people were gracious, so they let him in. For months he toiled away at working on the engines, with one popular addition to the engines available for the people to purchase. He worked tirelessly, for long days and nights, to make the engine as powerful as he could. He was getting close to releasing the biggest and best of his additions yet. In fact, he may well have released the addition in a few days post to his experience, of which shall now be told. The brave knight, Sir Jones, had come back from fighting the troops of Wordpressia, and decided that the engines needed an upgrade. He issued the upgrade warrant, and the people got to work at upgrading their engines. The Joker, however, was a fool. He forgot to take the correct steps in upgrading. He forgot to clone his engine before hand, so none of the precious parts were lost. He didn’t bother investing in a version control system for his engine. He passed by on Sir Jones’ question to ensure that nothing like this happened. All his hard work, all his sweat and blood, had been lost. Months of work, months of additions. Lost. Blown into the wind never to be seen again. The Moral? So, I lost 2 months work on Taggable. I’m going to have to pretty much start from scratch - 1.2 was a pretty big rewrite and I’ve lost everything that I’ve done. As well as Taggable, I’ve also lost Judge, EngineRoom and Carousel (more on them later). Luckily, I’ve still got the Sparkplugs site, which is a relief. Anyway, I’m setting up remote backups for my Sites directory ASAP, and will be promptly putting everything into version control. It’s taught me a big, big lesson. 2010-05-02T08:15:52+00:00 http://jamieonsoftware.com/blog/entry/screen-scraping-with-php http://jamieonsoftware.com/blog/entry/screen-scraping-with-php#When:08:24:02Z There are quite a few good screen scraping libraries available for PHP apps so that you can pull and parse a page, search for specific elements, enter data into and post forms et cetera, but if you just need to do a bit of screen-scraping work and you don’t need an entire library (or don’t want the additional overhead of another file to load), PHP has a few handy tricks up its sleeve to make this really easy. Getting the source Getting the source code of a HTML page is really easy. You could go down the route of using cURL if you need a lot of control over your requests, want to make asynchronous requests or need to use any other HTTP method than GET, but for basic stuff, file_get_contents works absolutely fine. <?php $html = file_get_contents('http://codeigniter.com'); After you’ve got the source code of the page, we could clean it and get some nice, valid XHTML using PHP’s Tidy Extension, or we could just hope that it’s valid enough so our parser can understand it. In this case, as I know the CodeIgniter homepage has got some pretty good markup, we’ll do the latter. Parsing the HTML Parsing the HTML we’ve downloaded is seriously easy. We want to get it into a form where we can use xPath to scan through the source and find the elements we want. To do this, we’ll use a method which is without a doubt full of win. We create a DOMDocument object, set $strictErrorChecking to FALSE (HTML isn’t usually strict enough) and run the loadHTML() method. <?php $dom = new DOMDocument(); $dom->strictErrorChecking = FALSE; $dom->loadHTML($html); With this DOM document, we now have an objectified representation of our remote page. The final step to screen scraping karma is to push this object into a SimpleXMLElement, with which we can fully traverse and manipulate the document. <?php $obj = simplexml_import_dom($dom); Win. Okay, now we can use this SimpleXML element to run XPath queries on our document. We’re going to find the two lists on the CodeIgniter homepage under the CodeIgniter is right for you if… section, then loop through their elements and display them on our own site. Taking a quick peek at the CodeIgniter.com source code shows us that the lists are <ul> tags and they have the IDs of column1 and column2. <?php $lists = $obj->xpath("//ul[@id='column1'] | //ul[@id='column2']"); Collecting the reasons Now we’ve got these elements, let’s loop through them and collect the reasons. <?php $reasons = array(); foreach ($lists as $list) { // obj { li = array() } foreach ($list->li as $reason) { $reasons[] = (string)$reason; } } We’re looping through an array of two elements (both lists), and each list has a number of <li> elements. We loop through those and collect their values. We need to remember to cast the $reason object as a string so we can see the string itself, rather than it’s objectified representation. Wow, that was pretty easy. Now all we have to do is loop through the reasons and output them, and we’ve completed our little screen scraper. <?php echo("<h1>Why is CodeIgniter right for you?</h1><p>"); echo implode(', ', $reasons); echo("</p><h1>CodeIgniter provides all these reasons, and more!</h1>"); Great, we’re done. So there we go, that’s how you write a simple screen scraper in PHP. 2010-04-26T08:24:02+00:00 http://jamieonsoftware.com/blog/entry/the-playa-effect http://jamieonsoftware.com/blog/entry/the-playa-effect#When:16:33:13Z There are very few times when you get to test out a genuinely exciting product - something that is revered and well known across a community and is hugely anticipated. I’m lucky enough to be able to test out the latest version of Brandon Kelly’s infamous Playa, which yesterday hit version 3. This update, among other things, introduces ExpressionEngine 2 support, a snazzy new interface and loads of bug fixes. I’ve been testing it out for a few days, and here’s my review. Installation Installation was pretty much seamless. I’ve been working with an alpha/beta copy, so there were one or two bugs that I encountered, but I reported them to Brandon and since then have been fixed. For those of you who are upgrading from Playa 2, there is an upgrade script that makes it easy to pull your data over. The New Interface The new user interface in the control panel is absolutely lovely. It’s fluid, intuitive and extremely easy to use and understand. It feels smooth and polished; and is an utter joy to use. I’d like a few more filtering options, as well as the ability to be able to sort by various fields dynamically on the publish form, but all in all, the interface is extremely well put together. Template Tags …are great! I can’t think of anything else I’d ever need here. Almost mimics the {exp:channel:entries} tag, and that’s due to the fact it actually implements EE’s relationship functionality it at a lower level. Price Playa is a little pricey, but by all means every penny is worth it, and Brandon’s support is fantastic. It’s a fair price to pay for what Brandon has done for the EE community, and it’s an incredible product that I can only see getting better and better. So, buy it All in all, Pixel and Tonic’s Playa 3 is a fantastic EE2 addon. It’s powerful, simple, sexy and elegant. I would recommend it to anyone. 5 stars. 2010-04-13T16:33:13+00:00 http://jamieonsoftware.com/blog/entry/wrap-me-up-and-put-me-in-a-box http://jamieonsoftware.com/blog/entry/wrap-me-up-and-put-me-in-a-box#When:10:52:39Z One of the additions that I’m most excited about to the in-development CodeIgniter 2.0 codebase is the addition of code packages, and the power to then load those packages inside your application. This opens so many doors to developers, because, finally, we can bundle repeated functionality inside a package and distribute it as open-source or free code. Even if you don’t want to expose your own packages, you can re-use them internally, which makes for a veritable mix of both writing application specific code, and abstracting elements of those applications out (such as an authentication engine, for instance) to become re-usable and unspecific. With documentation for 2.0 still patchy, I thought I’d go through exactly how to use packages and what benefits they provide. Relative Positioning Packages count as application-specific code in themselves, and so are generally put in the application/third_party directory. A single package directory can contain its own controllers/, models/, views/, libraries/, config/, helpers/ and language/ directories. Think of them as mini-cities inside a bigger city. Sprawling metropolises inside vast underground caves. Want to put your packages somewhere else? No problem. Currently, as the loader for 2.0 is still under development, you’re not tied down to a specific location. At some point, no doubt, the location of packages will be finalised, but even after EllisLab set the recommended location, there will still be the underlying package API, so you won’t be stuck with using application/third_party. Lock and loading In this current stage of early development, loading packages is somewhat fragmented. Currently, you use the loader to add the package’s path to the list of resource paths. When a file is loaded with the loader, the loader checks in that file’s respective path(s) for the file, working based on an order of chronology. If the loader can’t find the file in the application/libraries directory, it will look in the first package path you add, then the second, then the third, then any subsequent to that. That means that you can’t have conflicting classes or files your application. Adding package paths is simple: <?php $this->load->add_package_path(APPPATH.'third_party/mango/'); Here we add the mango package to the list of searched directories. We can then load any subsequent classes inside the mango package using the loader just like before. <?php // Load mango/libraries/resources.php $this->load->library('resources'); // Use the library $juice = $this->resources->juice(); $oil = $this->resources->oil(); // Load mango/models/juice.php $this->load->model('juice'); $prepared_juice = $this->juice->prepare($juice, $oil); // We can also load any application-wide files // Load application/libraries/drinks.php $this->drink->create($prepared_juice, "Mango Juice"); If you are working with multiple package directories, you can remove packages from the paths array after you are finished with them. After you’ve finished devouring the flesh of your delicious mango, you can suck clean the stone in the middle and put it in the bin, before washing your hands. <?php $this->load->remove_package_path(APPPATH."third_party/mango/"); Views and mangos Unfortunately, there is still one loose link in the chain. That odd mango that turns rotten, mushy and spoiled to both the tongue and the eye. View loading is still inherently difficult, for some strange reason. If you wish to load views inside packages, you must manually set the loader’s load path to the views directory inside your package, and then back to the original load path after you’re done. The simplest way is to wrap it up inside a helper method: <?php public function view($name, $params = array()) { // Keep the original path and set the active path to the mango/views directory $orig_path = $this->load->_ci_view_path; $this->load->_ci_view_path = APPPATH.'third_party/mango/views/'; // Load the view $this->load->view($name, $params); // Revert back to the original load path $this->load->_ci_view } That cleans things up a bit, because now all you have to do is call: $this->view('fruit/details', array('fruit' => 'Mango')); Routing and more Packages aren’t really there yet. They’re cool, and they provide a lot of promise, but as CodeIgniter 2.0 is mercifully under development, you can’t do a few basic things that really are necessary, such as routing to a package or autoloading package paths. I’ll revisit this topic in a few months when packages are more stable and you can do more with them. However, they are still pretty useful for grouping code together, sharing code across multiple applications, and the addition of proper routing, view loading and autoloading will just sweeten the deal. 2010-04-09T10:52:39+00:00 http://jamieonsoftware.com/blog/entry/testing-restful-response-types http://jamieonsoftware.com/blog/entry/testing-restful-response-types#When:15:07:32Z I’ve been doing a lot of Rails development recently as part of my new job (our whole infrastructure is built on Rails, you see), and have been practicing Test-driven Development religiously. As part of this, I’ve been developing an API that returns more than one response format, and I was looking to find out how to test if the correct response type is being returned. The way I approached this was using the @response.content_type variable, and running an assert_equal, comparing it with the correct mime type: test "that the response type is JSON" do get :index, :format => 'json' assert_equal @response.content_type, 'application/json' end That worked fine for a while, but I slowly grew tired of repeating myself and having to copy and paste content types. Also, the above solution isn’t particularly flexible; as far as I’m aware, there are 6 different accepted content types for JSON alone. What if I were to copy and paste this code into, say, a Sinatra app or some other app where I was writing my tests in Ruby, only to find it returned a different content type and my tests were incorrect? So, I decided to abstract the method out into my test_helper.rb into it’s own assertion method. This method would take a symbol to specify what response type to check, check the actual response type against a pre-defined list of response types that are grouped under the response type of the symbol passed in, and assert that it was included in the array. It looked something like this: def assert_response_is(type, message = '') case type when :json check = [ 'application/json', 'text/json', 'application/x-javascript', 'text/javascript', 'text/x-javascript', 'text/x-json' ] when :xml check = [ 'application/xml', 'text/xml' ] when :yaml check = [ 'text/yaml', 'text/x-yaml', 'application/yaml', 'application/x-yaml' ] else check = [] end assert check.include?(@response.content_type), message end Again, that worked fine, but there were still a few issues with it. What if I wanted to check another response type that wasn’t predefined? How could I add that? I decided to use a bit of Ruby’s metaprogramming to check for a method on the current class. That way, if I wanted to add any more content types I could define that method and it would check against the array returned: # ... else if methods.include?('assert_response_types') check = assert_response_types else check = [] end end # ... Almost there. The penultimate thing I noticed was that the script was still specific to Rails, as it was checking the @response.content_type variable. So, I used the same technique as above: # ... if @response.content_type ct = @response.content_type elsif methods.include?('assert_response_response') ct = assert_response_response else ct = '' end # ... Great! Finally, I wanted the failure message to be a bit more descriptive than “ is not true”. I dug around a bit inside the Ruby Standard Library and found that the default Test::Unit assertions raised a Test::Unit::AssertionFailedError when an assertion failed. Also, I discovered the helpful build_message function that builds up an error message. So, all I had to do was rescue assert’s exception and raise my own with my own custom message: # ... begin assert check.include?(ct) rescue Test::Unit::AssertionFailedError raise Test::Unit::AssertionFailedError.new(build_message(message, "The response type is not ?", type.to_s)) end end Tie all this together and I have a pretty neat assert_response_is assertion, to check that the response type is a certain value! The entire method looks like this: def assert_response_is(type, message = '') case type when :json check = [ 'application/json', 'text/json', 'application/x-javascript', 'text/javascript', 'text/x-javascript', 'text/x-json' ] when :xml check = [ 'application/xml', 'text/xml' ] when :yaml check = [ 'text/yaml', 'text/x-yaml', 'application/yaml', 'application/x-yaml' ] else if methods.include?('assert_response_types') check = assert_response_types else check = [] end end if @response.content_type ct = @response.content_type elsif methods.include?('assert_response_response') ct = assert_response_response else ct = '' end begin assert check.include?(ct) rescue Test::Unit::AssertionFailedError raise Test::Unit::AssertionFailedError.new(build_message(message, "The response type is not ?", type.to_s)) end end And my tests look like: test "that the index method returns all users in all formats" do # json get :index, :format => 'json' assert_response_is :json # xml get :index, :format => 'xml' assert_response_is :xml # yaml get :index, :format => 'yaml' assert_response_is :yaml end So there we go, that’s how to test RESTful response types in Ruby, using Test::Unit. I’m still pretty new at using Ruby, so any Rubyists feel free to take and make my code nicer! 2010-04-02T15:07:32+00:00 http://jamieonsoftware.com/blog/entry/codeigniter-repo-naming-conventions http://jamieonsoftware.com/blog/entry/codeigniter-repo-naming-conventions#When:14:28:50Z With the announcement that CodeIgniter 2 is now under public development over at BitBucket, lots of developers have been moving their open source projects over to Mercurial, and thus BitBucket. With such a big change that is starting to be reflected across the community, I propose we create a globally used convention for naming BitBucket Repositories (or GitHub, for that matter) that contain CodeIgniter-based libraries or projects. I suggest we prefix every CodeIgniter-specific repository with codeigniter-. I’ve been doing this, as has Phil Sturgeon, but others (I’m looking at you Haughin) haven’t, and it’d be great to have this global convention set up. It would make finding CodeIgniter repositories much easier. Spread the word, and hopefully we’ll have a really good consistent way of naming BitBucket repositories. 2010-03-27T14:28:50+00:00