Richard Hart

Richard Hart

Head of Something @ Somewhere
Kent, UK

My Music
My Photos

LinkedIn
Mastodon

  • Business Design Principles

    Facebook’s Four Business Design Principles is an excellent reference that should be at the core of every business tool.

    Help people learn and grow

    Balance efficiency and effectiveness

    Bring clarity to complexity

    Be accurate and predictable

    The majority of my time these days is spent writing tools for business as opposed to consumer facing sites and trying to find the balance between ease of use and providing all the elements necessary to complete a task can be very difficult at times. I had not heard of the Goldilocks Principal before but it perfectly summarises this fine balancing act.

    With a complex piece of UI, if you don’t simplify it enough, people can’t figure out how to use it. But if you swing too far in the other direction and over-simplify it, you risk dismantling the very value that people are looking to access through the tool.

    When immersed in a tool it’s easy to become blind to the experience of actually using it. A good example are the drop down menus on a site I’ve been working on these past few years. Even though we would all use them day to day they were never really given a second thought. It was only after looking into how they were actually performing that it was apparent that they were actually really awful to use. Our own familiarity had caused a massive disconnect between how effective they were to use.

  • BEM CSS

    All too often I find that CSS quickly becomes a real tangle of clashing styles and names. No matter how hard I try something always ends up breaking the styles of something else. Moving to SASS helped a lot but I find on the flip side I end up with styling that’s overly nested.

    I’ve recently come across BEM which is CSS methodology for naming classes. BEM stands for Blocks, Elements, Modifiers. I’ve previously looked into SMACSS but still found things fell apart (probably because I’m doing it wrong). BEM looks a lot simpler and easier to maintain. A simple example would be the following styling for an article.

    .article // Block
.article__body // Element
.article--featured // Modifier

    I’m not going to go into much detail as there are already some great posts out there on the subject. I still feel like CSS itself is a bit of a broken solution, although I can’t articulate why or what would be a better option.

  • Who designs car parks?

    Riddled with tight gaps and high kerbs they are the often the most anti-car friendly places on earth. I am convinced that the people who design car parks must be sadists.

    I have yet to see a car park wall that isn’t covered in different colour streaks from all the mis-judged turns. Why not have sloped kerbs so that you don’t scuff your wheels or bodywork if you misjudge the spacing? Why not give a little bit more space instead of tight turns at every opportunity? You wouldn’t pay to stay at a hotel where they punch and kick you at every chance they get before you reach your room. Why is it acceptable for our cars?

  • I’m a pirate but I’m open to options

    Pirating TV shows, music, games and applications is just so ubiquitous these days. Where as once it took some degree of knowledge, now everyone seems to do it. I don’t believe people pirate things because they want to steal but because there are no reasonable alternatives.

    For instance, since getting a Spotify Premium account, I haven’t downloaded any music. I dislike pirating shows as I feel that by doing so I’m not really showing any support for the ones I truly love. I could wait months (or even over a year in some cases) to catch it on Netflix or Amazon Prime but then I miss any ability to join in with the conversations with those that have already watched it. I would happily pay for the ability to watch show as soon as they are broadcast, or even a day or two later, seeing as I mostly watch US shows. This is of course a very simplistic view and the politics and logistics around doing something like that are extremely complicated, but I can still dream. At the same time, just shut up and take my money!

  • Better sort by rating with Spree and spree_reviews

    The blog post How Not To Sort By Average Rating continually pops up and got me thinking about how we currently implement sort by rating. We currently use spree_reviews for capturing ratings and it takes a very simplistic approach to storing the average rating for a product:

    self[:avg_rating] = reviews.approved.sum(:rating).to_f / reviews_count

    This exact scenario is mentioned in the blog post above:

    Why it is wrong: Average rating works fine if you always have a ton of ratings, but suppose item 1 has 2 positive ratings and 0 negative ratings. Suppose item 2 has 100 positive ratings and 1 negative rating. This algorithm puts item two (tons of positive ratings) below item one (very few positive ratings). WRONG.

    A better solution is using a Bayesian estimate which actually takes the number of reviews into consideration. This is how IMDB currently create their top 250 movie list:

    weighted rating (WR) = (v ÷ (v+m)) × R + (m ÷ (v+m)) × C

    where:

    * R = average for the movie (mean) = (Rating)
    * v = number of votes for the movie = (votes)
    * m = minimum votes required to be listed in the Top 250 (currently 1300)
    * C = the mean vote across the whole report (currently 6.8) for the Top 250, only votes from regular voters are considered.

    With that, it’s fairly simple to approximate with spree_reviews. Just be sure to recalculate all your product ratings.

    Spree::Product.class_eval do
  def recalculate_rating
    reviews_count = self.reviews.reload.approved.count
 
    self.reviews_count = reviews_count
    if reviews_count > 0
      r = reviews.approved.average(:rating).to_f
      v = reviews.approved.count.to_f
      m = Spree::Review.approved.count.to_f
      c = Spree::Review.approved.average(:rating).to_f
 
      self.avg_rating = (v / (v+m)) * r + (m / (v+m)) * c
    else
      self.avg_rating = 0
    end
    self.save
  end
end

  • Into the abyss

    Beware that, when fighting monsters, you yourself do not become a monster… for when you gaze long into the abyss. The abyss gazes also into you. Friedrich Nietzsche

  • Zen and Happiness

    There is no need to start happiness after 20 years. You can be happy right now, even when you are not a Partner or don’t drive a Porsche. Things change to easily. You can get sick. You can get fired. You can burn out (if you follow all these items I guess likeliness is low).

    Until these bad things happen, just work as well as you can and have fun with doing it. No reason to look at the gains of the colleagues. No reason to think about the cool new position which you didn’t get.

    After all, you will reach something. You’ll end up with nice memories, maybe a good position – and 20 excellent years. Every day is a good day.

    Zen Monks are not to shy with their work too. They get up at 4am (sometimes earlier, sometimes later, depends on the convent) and start meditation and work (they even consider work meditation practice). They have stuff to do like cleaning the toilets. Or working in the garden. Or as a Tenzo, they cook. They do it with all the care they can get. What ever they do, they do it without suffering and they are (or should be) happy, because every second, even the second where they are cleaning toilets, is a second of their life.

    Even pyramids get lost, after a long time. Do you know the names of the people who build up a pyramid? And if you do, is it important that you know? It’s not. Pyramids are there, or not. Nothing special.

    From the The 10 rules of a Zen programmer. A post I’ve read many times as there are so many gems within it.

  • The technical debt of your former self

    As we mature and become better developers there’s a funny case of code we previously wrote taking on a certain amount of technical debt purely because we have more experience and knowledge on how to tackle the same problems. We’ve all been there, having gone back to look at code we thought was great at the time to only wonder what the hell we were thinking, or gone back to reduce a long method to a single line. Technical debt is inevitable if we continually seek to improve our skills.

  • First things first

    I have a small check list of things I aim to do every day. This includes things like meditate, write, vlog, foam roll/stretch etc. The problem is I put off the majority of them until late at night and on most occasions end up skipping them in favour of going to bed. While I get to say I got some of the things done, I’m still treating them as an after thought to the rest of my day. Really what I should be doing is putting first things first and getting these things done before I do anything else. Why am I putting things like browsing the news, Reddit and YouTube first? I tell myself “Well I’m just getting started, I need to ease myself into it”, but really that is just an excuse to put things off. So from now on I’m going to start putting first things first.

  • Not so remote

    Fostering a team feeling when everyone is remote can be extremely difficult. It’s easy to feel like you are working in a total silo, and can be made worse if everyone is spread across distant timezones. Being able to function as a team is a key component to project success. Feeling isolated and alone when problems come up can make work frustrating and stressful at times. Here are a few ways to try and overcome that:

    • Try and arrange core hours where the whole team is available and together on Skype/HipChat/Slack.
    • A weekly call with everyone to update on work, issues and client feedback.
    • A daily call between project managers and members of the team to chat about current progress and the project as a whole.
    • Code sharing sessions. Show code to other members on the team and explain what features are and how you’ve gone about implementing them.

  • Move fast and break things

    I was thinking about the “Move fast and break things” approach to projects this morning. A few projects I’m currently working have been moving at a snails pace and the longer projects go on and the bigger they get before being launched fills me a certain kind of dread. I feel really comfortable launching with a few half baked features rather than everything in one big bang. When there are so many moving parts in a launch, no matter how much you test, real users are going to find problems, and trying to keep on top of them can drive you insane. It’s the difference between trying to steer a small sail boat vs a cruise liner. If you start small you can probably respond quickly to change and get to where you want to go than if you launch big and try and change course later on.

    Now I don’t condone breaking things, but I do agree with the idea of moving fast and staying agile. So just “Move fast”, that’s all you have to do. Accept that things will break and things will need improving.

    “A good plan violently executed now is better than a perfect plan executed next week.” – George S. Patton

  • Generate a random email address in TextExpander with Ruby

    Made this short snippet to help generate random email addresses using TextExpander. Set the snippet content type to “Shell Script” and paste in the following. You’ll need Ruby installed which comes with most modern versions of OSX.

    The snippet will generate a different address every minute and copy it to your local clipboard incase you want to paste it in again. It also uses YOPMail which you can check for emails too.

    #!/usr/bin/env ruby -U
email = "#{Time.now.strftime("%m%d%H%M")}@yopmail.com"
IO.popen('pbcopy', 'w') {|io| io.write(email)}
print email

    Update: I have a new post on how to do the same using AppleScript.

  • Hard Deadlines

    On almost every single project I’ve worked on, hard deadlines have nearly always been the cause of any stress or frustration that arises. One day you’re asked to make rough estimates and then next thing you know they become pegged to a date in the future that you must meet at all cost (But you said you think it would only take X days!). Even worse is when someone non-technical makes the estimates for you and passes them down from on high (Look, this is the all the time we have, I’m sure you’ll be fine!).

    Why do we still insist on having hard deadlines? Yeah I know, we asked for more features but now the project is “late” so you’ve failed to do your job. Yet, if the deadline wasn’t concrete, the project would have more features then initially scoped and delivered in a timely fashion, you’re a success!

    New features are always requested, changes are always wanted and bugs will always be found. If everyone just accepted (understood) that writing software isn’t exact science then we’d all have a lot less stress to deal with and we can stop feeling like a failure for not meeting that pie-in-the-sky deadline.

  • Cake

    Two people want to share a cake.

    The reasonable person asks for half the cake, the unreasonable person asks for the whole cake.

    They compromise and split the difference – the unreasonable person gets three quarters of the cake and the reasonable person gets a quarter.

  • The Sin of Not Improving

    “It’s no sin to be a beginner or an intermediate. It’s no sin to be a competent programmer instead of a leader. The sin is in how long you remain a beginner or an intermediate after you know what you have to do to improve.”