Copying files to a Synology NAS was painfully slow with Carbon Copy Cloner. Following the official help of ejecting the volume in Finder made all the difference. Syncs now happen as fast as they should do.
Since my last post about generating random email addresses in TextExpander, I’ve move from using Ruby to Applescript to do so. Here is my script which essentially does the same thing.
set email to (do shell script "date +%s")
set email to email & "@yopmail.com"
set the clipboard to email
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.
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 do 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 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!
Here are some of my thoughts on Casey Neistat‘s new app Beme. Beme is a video sharing service with some quirky features. Firstly you hold your phone to your body to start recording, there’s no preview and you can’t see what you’ve recorded afterwards, you can view other people’s Bemes and once you’ve seen it, it’s gone forever and lastly you can send a photo reaction in response. It’s a nice idea but I think there are a few things that let the concept down.
There’s no sharing. If I see something great, I can’t turn to the person next to me and show them what I just saw. It’s gone forever. I can’t share it via email, Facebook, Twitter, etc.
I can’t see a person’s body of work to see if they’ll be someone worth following in the future. Is this person into the same things I’m into? Will they be creating great Bemes in the future? Who knows. It’s a crapshoot.
Being able to look over past posts and photos is what makes some sites like Instagram great. It’s nice to see where people were and where they are now. To relive those great moments from our past. Those great moments you shot on Beme. Gone.
Those things combined are what would keep me from opening Beme in comparison to Instagram/Snapchat/Whatever. Maybe they’ll find ways to be successful in spite of those things. If there’s one thing the past has taught me about technology companies, is that you can’t write anything off. Sometimes the weirdest ideas just turn out to be some of the most successful.
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
* 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.
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
self.avg_rating = 0
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.
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.
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