28
Jan
2015

Why I moved my static blog to HTTPS

by Alex Savin

Fialka ciphering machine
Photo credit Brett Neilson

By the year 2015 general awareness of the differences between plain HTTP and protected HTTPS seems to become more or less general. When making online purchases, or sending private messages, or entering passwords online we are now getting this warm fuzzy feeling if there is green lock icon shining next to the page’s URL. And panic attacks if there isn’t one. Being HTTPS only became standard for online services dealing with customer sensitive data.

On the other hand there are pages like personal blogs, or, well, Wikipedia. Or BBC. Just good old unencrypted HTTP. You can actually access Wikipedia via https, but if you try the same trick with BBC page, it will just redirect you back to the land of plain HTTP. And why would you want encrypted connection anyway? It’s not like they are selling stuff and you’re submitting personal credit card number. You’re just wandering around the Web, reading stuff, minding your own business.

Recently I moved my personal blog pages to be HTTPS only. Here are few reasons why.

  1. With plain HTTP there is no certain way of telling if you are actually reading my blog. You type URL in the browser (or click a link), and browser politely requests content for this address. During the journey of this request, at any point it can be read, interpreted, and responded with any content. And the browser will display whatever is returned.

  2. A classic example would be man-in-the-middle attack. Open unencrypted traffic allows anyone on your (free) wifi network to intercept it, track your requests, as well as potentially alter content of the page. With example of BBC pages, you could inject some news articles, or in general alter the content in any possible way.

  3. If you think that only evil hackers would do such atrocities, think again. There are reports of in-flight and hotel wifi networks injecting banners into webpages. Goes without saying that this would not be possible with HTTPS pages.

  4. Google started using HTTPS support on the page as a positive ranking signal last year. Meaning, HTTPS pages will be ranked higher than plain HTTP only pages.

  5. HTTPS traffic is much harder to block and filter out with corporate firewalls. You would have to force install additional certificate onto machines in that network (which is a common practice in certain places).

  6. In general, living in post-Snowden era, when TheVerge reveals new details on digital surveillance almost weekly, strong reliable encryption of everything seems like a very good idea.

  7. One interesting topic is state controlled firewalls, like Great Firewall of China. Wikipedia article on this matter contains following curious trivia:

The Tor anonymity network was and is subject to blocking by China’s Great Firewall. The Tor website is blocked when accessed over HTTP but it is reachable over HTTPS so it is possible for users to download the Tor Browser Bundle.

The very same Google recently announced that not all SSL certificates will be treated equal, and SHA-1 certificates are going to be retired and indicated as unsafe already in Chrome 41. In a way, it is a danger in itself to blindly trust any SSL certificate. There are quite a few online tools to test various security aspects of your SSL – the best and most helpful being SSL Test. It will test pretty much everything, and provide you with a grade and bunch of hints how to improve it, and why it is capped (if it is).

One notable thing about SSL Test is that once you decide to buy a certificate, you can run this test against pages of the issuer, to make sure that it is indeed legit, and there are no issues like broken certificate chain.

This post is inspired by HTTPS everywhere talk on Google IO 2014, and this ATP podcast episode.

23
Jan
2015

2015: Native App Development is Dead in the Enterprise

by Cain Ullah

With Gartner results showing that in 2014 mobile and tablet sales equated to approximately 2.4 billion unit sales compared to 318 million PCs and with an ever increasing proliferation of mobile devices, for many enterprise level organisations developing an effective mobile strategy continues to be one of their biggest challenges.

So what questions are organisations currently asking themselves when devising a strategy for a successful mobile presence?

Native vs Responsive

There has been a long standing argument between the value of building native applications specific for a device such as an iPhone or Android vs. the mobile web i.e. responsive web sites that work across all devices.

The nirvana is that developers wouldn’t have to worry about devices at all and that there would be a solution to write an application once, for it to cover all use cases and work on all devices be it in the guise of a native app or a website. Unfortunately this doesn’t yet exist and Facebook’s attempt at doing this via HTML5 was followed by a rapid backtrack that was well publicised.

There are obvious pros and cons to both (you can read David’s article here for some great insight into why responsive web design is a great strategy). Native applications give you more flexibility when accessing a smartphone’s features (such as the accelerometer) and there is the obvious advantage of offline browsing. However, native applications are only built for a specific device resulting in you having to build multiple applications; development costs and ongoing maintenance escalate as a result. Responsive websites on the other hand can be built once and work on most devices (if tested properly) providing a far greater reach for less development cost. But offline browsing is not easy and user experience can often be hindered by the limitations of HTML.

At the moment there are use cases for both that solve separate concerns. If you have a complex set of requirements you may not be able to avoid the need to have to build both a website and a native application. It is common place for enterprise companies to have many desktop applications each with 3-4 mobile applications to support them.

Enterprise strategies differ from company to company. A fine example is The Times newspaper. They have focussed more on the optimum interactive experience of their native applications for both Apple and Android tablets, with separate editorial teams dedicated to each device. The website on the other hand is not responsive. They’ve not even bothered to redirect to an m.site, instead just displaying the desktop site on a mobile with a link to download the app from the app store.

In contrast to The Times, the Guardian has opted for a great adaptive/responsive website detailed in David’s aforementioned article from October 2013.

So is there a happy medium?

Cross Platform Tools

To tackle this problem, there are tools in the market that facilitate cross-platform mobile development such as Phonegap and Titanium. These allow you to build apps using Javascript and Web Technologies, and deploy them to  multiple marketplaces in the guise of native apps, across multiple platforms. The advantages on the surface are obvious – you get access to native features that are not available to web browsers but you also only have to write and maintain one code base. If only it was that simple.

There is a great blog highlighting the comparison and the weakness of both Phonegap and Titanium by Kevin Whinnery here.

Other cross-platforms also exist. Another blog by Kevin Whinnery’s former colleague, Matt Schmulen provides details on the options and how they fit into the current mobile ecosystem where there is an ever increasing demand in the Enterprise.

These frameworks include:

  • PhoneGap/Cordova (HTML/JavaScript)

  • Titanium/Appcelerator (JavaScript)

  • Mono/Xamarin (C#)

  • Rhodes (Ruby)

  • Kony (Lua)

Our experience of these cross-platform mobile development tools is that you simply cannot replicate the native app experience. We have experimented with these tools before, an example being the build of the mobile applications for our BMW project using Phonegap. We found that the iPhone version of the app was great. However, getting an optimum experience on Android took a huge amount of effort in optimisation and testing to get it close (but still not close enough) to a native experience.

So what does the future hold?

Native App Development Is Dead in the Enterprise

Mobile

This is a bold statement that will take some time to become completely true. However, 2015 is going to be the dawn of a new era of technology that will replace existing cross-platform tools such as Phonegap and Titanium with a much better offering that will finally succeed where Phonegap and Titanium have largely failed. This will be the beginning of the end of enterprises building responsive sites with multiple native applications to compliment them.

Responsive websites, with the help of new technology will form the basis of the code for native applications without hindering user experience. The applications will be fast and responsive, and there will be a single code base with very little device specific code.

What does this mean? Software companies like Red Badger that currently focus on the enterprise web (i.e. responsive web sites and not native applications) will also be able to deliver great native applications without a great deal of additional effort or the need to hire native app developers. Native application agencies are going to have to adapt and re-skill their employees in order to keep up, or face the consequences of withering into eventual obscurity. The winners will be the enterprise companies. They will have options available to them to  build great experiences across web and native applications on multiple devices with close to a single code base. This means fewer applications, less maintenance, lower development costs and happier customers.

This will ultimately kill the question: “should I build native or responsive?”. Why choose when you can have it all?!

P.S. Where’s my proof you may ask? Watch this space.

23
Jan
2015

January London React Meetup

by Roisi Proven

1_red_badger-38-x3

January 21st saw the first React meetup of the year, and we packed as many people as we could squeeze in to the Red Badger office for another round of talks from teams around London who are using React within their organisations. This month we had Jof Arnold, VP of Product from timecounts.org, Gary Champers, a Software Engineer at Football Radar, and Christian Moller Takle from Billeto.

Jof Arnold – from Backbone to React

Jof has been a long term attendee of our React meetups, and we were excited to have him step forward and share his experiences with us.

After a painful experience with using purely Backbone, Jof and the team at timecounts.org discovered React. There were elements of backbone (isomorphism and Backbone models) that he and his team felt they needed to keep, so they worked to merge Backbone with React to get the best of both worlds. Although it’s not necessarily the “correct” way of using React, it is a way to use React with Backbone without rebuilding everything from scratch. 

Gary Chambers – Go Reactive Building UI with Rx and React

Gary came over from Football Radar to join our roster of external speakers for this month.

Football Radar have a very data heavy system, and publishing hundreds of events a second then trying to publish them all to the DOM didn’t work out. After investigating alternatives to their current solution, they too came across React, this time using it in conjunction with Rx. Rx is a library for async dataflow programming, or in other words, a methodology for “data first” thinking, which Football Radar needed. He then went on to discuss how you can translate Rx into Flux, to really get the most out of React.

Christian Moller Takle – Whirlwind Tour of Functional Reactive Programming Using Elm-lang as a Base

Last but not least we had another of our React meetup regulars. Christian built upon the other talks, and took the stand to give an engaging, and very technical, talk.

Elm is a functional programming language that is “not scary, just different.” Christian spoke about Elm language and put a functional programming spin on the core tenets of React. Using Elm, Christian showed how, as in React, you can improve your UI development by modelling your UI as data, and discussed the common concept of the virtual DOM.

 

Here at Red Badger, we love hearing about new ways of using React in conjunction with existing technologies, so this set of talks really gave us a lot of food for though. I think several of our developers are particularly interested in delving further into Elm.

As ever, this Meetup was massively popular, and our humble Red Badger office now fills to bursting point at every meetup. As a result, we have been speaking with Facebook, who have kindly agreed to let us use their offices near Euston for the next React meetup. So expect bigger, better things, and lots more beer and pizza!

Sad you missed it? You can watch the full meetup over on YouTube

8
Jan
2015

Consumers in the driver seat

by Olga Loyev

Empty carI love math. So when it comes to analytics and stats, my brain smiles and my eyes spark, which is one of the things that attracted me to work at Red Badger. We are agile by nature and methodical in practice. We take analytical approach to problem solving and it is an integral part of the solutions we provide to our customers.

I’m a project manager for the Red Badger team at BSkyB where we recently delivered their new Help Site along with the supporting custom CMS to improve user’s ability to find the right content available and enhance their overall experience on the Sky Help site. As part of the the new solution we also added custom events tracking (things like clicks on links, buttons, page views, etc) that feed stats into New Relic Insights so we can closely monitor user behaviour to understand consumer’s requirements. The data we get back serves many purposes: from helping to prioritise work to highlighting outages to understanding customer demand and responding accordingly.

One example that stands out in my mind is what we saw recently on just another normal rainy day in London:

  • 80% of all unique visitors going to a specific article were clicking on “still need help” indicating they haven’t found the information they were looking for

  • 10% of all unique clicks on “still need help” across ALL articles were coming from that specific article. In comparison, the next article where most of “still need help” clicks were coming from accounted for only 5%

  • Daily top 10 most common search terms from the next action after clicking on “still need help” were referring to a specific issue the users were looking for help with

Notifying the stakeholders, we quickly found out that the information regarding the issue needed to be approved by the legal department before it could be published on the help site. Understandable, as it’s important to make sure product information is correct and consistent across different channels.

Fortunately, as soon as demand for this information spiked, we were able to immediately respond to the changing customer requirement and adopt the content to meet those. We shared the stats above with the legal department as soon as the spike occurred. The data highlighted the urgency of the request which was approved to be published within 15 minutes. The editors were then able to instantaneously publish the latest draft of the article which they already had prepared (thanks brand new CMS!) with the info customer was seeking. The published copy appeared on the live site 60 seconds after.

Within 12 hours, the percentage of all unique visitors to that article who still needed help after viewing the content dropped 50% from 80% to 40% with numbers levelling out to expected average by end of next day. Shazam! The power of numbers used for good!

Stats and analytics are powerful tools and should be at the forefront of decision making; driving the delivery of features (and in this case, content) based on real time user requirements. Put your consumer in the driver seat to best meet their online needs and bon voyage!

 

5
Jan
2015

My favourite talks from RubyConf 2014

by Albert Still

RubyConf - San Diego Convention Center

I’ve recently returned from San Diego, California where I attended RubyConf and I’d like to share my experience. Overall the conference was awesome and I learnt a lot. One of the big values of visiting the conference was experiencing the community behind the language. Chatting with other Rubyists, core contributors and even meeting Matz the creator. It made me appreciate what it’s all about and made the long plane journey from London worth it.

Videos of all the talks have recently become available on Confreaks and here are some of the talks I found especially interesting:

Isomorphic App Development with Ruby and Volt

This was a very interesting talk by Ryan Stout and his web framework Volt that runs Ruby on both the server and the client. It uses the Opal Ruby to JavaScript compiler which is apparently very good. Building this framework I’m sure is no easy challenge. But executed well it could make Ruby web development in the future a lot more productive with less context switching. A full stack web developer could get by only thinking about one language! It also means having the same code for validations and routing on both the server and client. It’s still early days for Volt but definitely one to watch out for. Check out the speed he makes a to-do app! And if you’d like to play with Volt quickly clone it’s todos3 app and get it’s server up and running.

Testing isn’t enough: fighting bugs with hacks

Interesting talk by Paul Gross about an additional strategy to fighting bugs. He references bugs such as the Mars Climate Orbiter which crashed due to ground based software that returned an output in the wrong units. And the Knight Capital $440 million trading loss due to some redundant code that interacted with the system. Writing tests and having testers is great but bugs are inevitable. He references Rails and talks about strategies, hacks and monkey patches to reduce bugs. For example Paul works at Braintree and as a security measure they don’t want developers writing code that will look up customers unscoped, they must always look up the the customer through a merchants has many relationship with customers.  So they added a “scoped find hook” which will throw a runtime error if a dev writes code that looks up a customer unscoped. 

Epic intro music: BLE beacons in Ruby

Christopher Sexton explains how we can play with Bluetooth Low Energy beacons and Ruby. Imagine a Raspberry Pi running a Sinatra app connected to a speaker and an BLE beacon next to the entrance of your office. The BLE beacon simply emits a UUID. And when a mobile with his iOS app built in RubyMotion receives this UUID it posts to the Sinatra app running on the Raspberry Pi . Which in turn can play that member of staffs theme tune. When I get the time I’m keen to buy a beacon and get my Raspberry Pi up a running. I had the idea to get the Sinatra app to allow us to post funny quotes we heard our colleagues say. And then when someone walks in the door it could announce one of their quotes!

Stress Testing as a Culture

João Moura talked about integrating stress tests as part of the build process for a 2014 World Cup app. He recommended cloud based load testing loader.io, it provides an API that a continuous integration server could use. This is especially interesting with regards to e-commerce platforms where slow page loads can lead to a surprising decline in revenue.

Best,

Albert

When somebody has learnt how to program a computer … you’re joining a group of people who can do incredible things. They can make the computer do anything they can imagine.

Sir Tim Berners-Lee, inventor of the web

5
Jan
2015

London React Meetup: Christmas Special

by Robbie McCorkell

React Logo

Last time I told everyone that we wouldn’t have a meetup in December, because we assumed you all would be partying too hard to care. However Christopher Chedeau, front-end engineer at Facebook and co-developer of React, decided to come for an impromptu visit. And with Christopher himself in town how could we not put a meetup on? So technically I wasn’t lying to you all!

We knew this would be a popular night, and we haven’t had the time to find a bigger venue just yet, so to avoid the crush of last time we decided to limit numbers for this event. For those of you that couldn’t get a ticket don’t worry, this was just a one off and we’re hoping to find a bigger place next time.

To kick off proceedings our own Stuart Harris talked us through his latest work on a client project. Since his last talk on building isomorphic applications using a custom react view engine for node, Stu and the team have been hard at work expanding on these ideas for a new project for the same client. This time Stu’s talk has the catchy title ‘Building Isomorphic Single Page Applications With Cursors Over Immutable Data’.

In this talk Stu describes a few new ideas that has been packed into his latest project. The first of these is an isomorphic router that allows the server and the client to respond to the same routes, making isomorphic single page applications much easier to build. He also describes how using immutable data structures can help enhance React’s performance, and how this also allows for the use of cursors to unify your application’s data across components. Finally he shows how this all fits together in a sample application along with some comments on testing in a component hierarchy. The source code for Stu’s demo should be available in the new year, and Red Badger is also working on a React template/framework using some of these ideas called Reflex which should be available to contribute to soon.

Next up was Christopher Chedeau to talk about how react was born, how it’s doing now, and what the future is for React. Here he spans quite a range of topics from React’s origins in writing markup in PHP for security reasons, to Facebook’s widespread use of React components today, to the controversial topic of writing CSS styles in within react components.

It was fascinating to hear about React’s humble beginnings, and to hear Christopher’s thoughts on the future of React. It would be unfair of me to try and do the talk justice on here, so you’ll just have to watch it for yourself in the video below! Christopher was also kind enough to stick around for a lengthy Q&A session afterwards which I know everyone appreciated (his talk starts around 55:35 in the video).

Our next meetup will be held around mid January, and we are hard at work finding a bigger venue to fit everybody in. We’ll let you know a date and venue as soon as we can but until then, a Merry Christmas and happy New Year to you all!

24
Dec
2014

UX Tip of the week: Making UX part of the Process

by Sinem Erdemli

Design has gone a long way. Roles have expanded from being a last minute add ons to product strategy influencers. 

Design is no longer seen as the last step of a process that makes a product look pretty to defining product scope. UX design as a profession has been creeping in businesses, as ‘user needs’ start being taken into consideration at board meetings. Now, managers are actually curious about their target users. They want to understand what makes them tick and what is a turnoff. This is all great, but too early to call it a day and go home…

Mom are we there yet?

No. We’re still not there yet. We seem unable to shake off the industrial mind set no matter how agile we are. Our industrialised minds are still programmed to deliver efficiently, we want fast returns to our investments and love performance charts that point upwards. We most certainly don’t like cards that go back, against the flow. 

The question is: How can UX and design be integrated in the development process?

At Red Badger, we work in agile. That means we talk to each other all the time (occasionally about work stuff), we change things, we question the decisions we made, check in with users and do it again until it is right. The designers, developers, testers they all sit together and work together. 

However, that process of close collaboration is difficult to capture on the Kanban board. The project board is there for a reason, it should be a mirror to team activities, it should communicate the process and the goal we work towards. But does it really?

Out of sight, out of mind? 

The issue with keeping UX as an isolated step in the process is that once the stories pass through and get closer to Done, the goals change. After a certain point, the goal becomes efficiency and you find yourself focusing on just delivering features, making sure they pass cross platform tests. 

We’ve talked about how crucial it is to keep your personas close and introduced Bob. If you haven’t seen that post do it-here and now.

We suggested sticking a picture of your version of Bob next to your computer, on the wall, by the project board. Somewhere you pass, and will see-daily. 

ALWAYS keep in mind that there will be people using your product (unless of course your target group is animals, insects, aliens..) It is important to have check-ins with users. Just like daily stand-ups you have with the team or weekly progress meetings with your client, make sure you check-in with the end users, and take a step back to make sure the greater goals and the purpose of your project are still there. 

kanban

  • Discovery: This is a good point to discover why you should get started in the first place. Find out about the strategic goals as well as the technical feasibility. Test the concept, go and get a feel for what the intrinsic needs and behaviours are. What people might like doing, what do they enjoy, who do they follow and most importantly why they do so. Use this space and time to go wild. Explore and question everything.
  • UX: You know the drill here. Use all the wisdom you have to do your magic. 
  • Design: Make sure the design reflects the brand direction, the look and feel is consistent with your intended messaging
  • Dev: Check that the high-tech features make sense to people who will be using the product
  • Test: Try to find out the different use scenarios, validate the assumptions you’ve made
  • Done: Watch usage, do some proper testing, measure and watch behaviour. Use all the data you’ve collected to write up new use cases, start thinking about improvements 

Disclaimer: We’re still testing this out. It’s already changed within a week. The user testing section doesn’t have to be a physical test with users, . 

It’s merely a suggestion rather than a solution- as always. Do try it at your own risk- we suggest collaboration over supervision. 

Until next time..

Ta!

17
Dec
2014

UX Tip of the Week: Meet Bob

by Maite Rodriguez

 

From the developers to creatives to business people, how to get everyone to finally understand the what UX is really about.

 

Let’s get started.

 

I would like to introduce you to Bob.

 

He will be our “user” for today.

 

 

Bob = User

 

For starters, you should always make it clear it is all about the “user” aka Bob.

 

Period.

 

If this is not absolutely clear from the beginning, then there is no point in reading the rest of this …..

 

Ta!

 

 

Stop using the term “user” to the team. These “users” are people with feelings like Bob. Try to use the persona’s name that the UX team meticulously researched and created for the brief.

 

Personas are there for a reason….

 

If you have to, frame a photo of your persona, let’s say Bob, and place it next to everyone’s computer as a daily reminder.

 

 

Let’s make this abundantly clear, people are not “stupid” or “slow” or “lazy”.

 

If your “users” do not understand the design, it is 99.999999999999%everyone’s fault involved in the project.

 

One team, One accountability.

 

 

If you are not there to defend the “user” … then who will? If there is no one representing Bob, then there is no UX.

 

 

Do not resort to the easiest tech solution. I know, it’s hard…

 

Mo’ work, mo’ problems.

 

But, if it’s for the “user” aka Bob’s best interest sometimes we all have to make sacrifices. As that great kung fu fighter once said in that kung fu movie:

 

“Take the hard righteous path than the easy wrong one to save the kingdom.”

 

 

UX is not like paint. We can’t just slab some paint on a chipped wall and call it a day. It is much more than that, so much more.

Here’s in on little insider secret…. UX doesn’t really exist.

 

UX is just a easy term that is used to group a whole lot of things that would take too much time to explain in one simple job title.

 

 

So, if you just take one thing from all of this, remember:

 

Every code written, every interaction made, every word read, every visual seen, the “user” should always be taken into consideration.

 

So, today I will rename the term “user” to “people” because it is all about the people’s experience…. Bob’s experience.

 

Until next week….

Ta!

 

10
Dec
2014

UX Tip of the Week: Post-its

by Maite Rodriguez

The Magic of Post-its

 

 

Post-its, Post-its, Post-its, Post-its, Post-its evuuuuurrryyyyy where..

 

All you need is a pen, wall space and post-its for your inner genius to come through.

 

When should you resort to post-its you ask?

 

  • Feeling overwhelmed with all the initial research and don’t know where to start….. post-it

  • Creating a christmas shopping list that you still haven’t started …. post-it

  • Need to do a feature analysis for a competitive website… post-it

  • Takings note at a meeting… post-it

  • Preparing a plan for action… post-it

  • Can’t decide where to eat for lunch…. post-it

  • Weighing the pros and cons of anything really… post-it

  • Need to prioritise and MOSCOW your project… post-it

  • Explaining to you co-worker how to get to Dirty Burger… post it

  • Trying to understanding foreign concepts (aka not related to UX) …..post it!

 

See! I challenge you to find a moment when the post-it can’t work its magic.

 

 

Until next week…..

 

 

 

4
Dec
2014

UX tip of the week: Competitive analysis for mobile navigation

by Sinem Erdemli

We started the week with user testing on an e-commerce site. It was all good until we asked people to find something, they had no idea how to work the side navigation.

And that was a surprise. 

tumblr_ltnymfq4NX1qen75u

It was obvious that users were struggling with it and it wasn’t a batch of those users who can’t work anything and have no idea what’s going on. There’s a limit to how much you can blame users.

The question in hand was obvious, one we had been pondering on for a while:

How might we get the benefits of a a mega nav on mobile?

So we went back to the office and got our post-its out. (Keep your eyes peeled for our next post on why post-its are king)

It was time to take a step back and clear our muddy heads. 

The game plan

1- List out relevant websites that have a similar issue (in our case it was squeezing mega nav content into mobile navigation)

2- Collect screenshots, the more you have the more ideas you can “steal” nope not that.. borrow

3- Break down the screens into it’s components. This is where the mighty post-it comes to play. 

4-List out Pros and Cons for each. Identify your favourites.

5- Sketch out the flow for each, find out how the users are lead to a particular Product Listing Page. How soon do they see the content? 

6- Compare flows. Visually comparing the flows let you highlight differences at a glance, it helps understanding (and communicating!) what works and what doesn’t. 

flow

6.a- If you can, go out and test the few examples with people, see if any alternative stands out, find out what people think. 

7-Show this to any stakeholder, it may be the client, it may be the designers, the dev team.. Talk about the issues users has, show the comparisons, think about what’s possible what needs more exploration..

8- Identify what you like, what can be done, with a little help from the favourite features list- and try it out. 

Taking a step back and looking around is useful. You clear your head, benchmark yourself among others and get to spend some play time.  Try it, you’ll feel better. 

Until next week, 

Ta.