Tobin Harris

In my never-ending quest to record acoustic guitar and sing at the same time, I've been looking at different ways to mic up the guitar. The problem I have is that my home studio is small and I can't really leave mic stands and cables everywhere, so I wanted something discrete yet very quick to pick up and play.

A few years ago, a bit of Googling revealed the DPA4099G - an condenser microphone that clips onto the guitar body. Despite that £400+ price tag, I decided to buy it. It's been "pretty good" and just lives on my guitar in the studio. I can pick it up and record immediately, which I love.

However, I've realised there are a few things that bugged me:

• It's a sensitive capacitor mic with cardioid a pattern, so it picks up quite a lot of vocal bleed
• My acoustic space is treated, but the dynamics fare better than condensers with my room and skills
• It's quite hard to point the mic away from your singing gob, whilst also being in the recording sweet spot where the neck joins the body
• The mic is a little close to the guitar. I'd usually have it 6"-12" away.
• I frequently knock the mic into a different position, or off the guitar altogether.

How to solve these problems?

1. Well, I'm thinkng I might be better with a dynamic mic to record the guitar. But nobody seems to make something like the DPA 4099G but with a dynamic mic.
2. A longer arm would also be useful, to get a little more distance and have more control over the sweet spot

So, I'm now on the hunt for alternatives. Since they're not easy to find at all, I've listed them here.

Exploraudio Liveguitar H-clamp

I really like the look of this one because it allow the mic to be further away, and it can hold an SM57 with excellent room rejection. It gets good reviews on SoundOnSound

More information here.

It's pretty easy to write unit tests for Flutter. The annoying thing is that there's no way to continuously run the tests each time you change a file. I find unit testing much better when tests run automatically as I code so I know when something is broken. I was hoping there would be a flutter test --watch but there isn't yet.

However, I worked out a hack that seems to work well.

brew install fswatch
fswatch -e ".*" -i "\\.dart$" . | xargs -n1 -I {} sh -c "echo $'\e[1;31m'{}$'\e[0m'; flutter test -j 2 ./test"

If you run this from the root of your application, you'll find that each time you tweak a .dart file, the tests all run again. There's probably a nice way to only run specific tests, but this will do me for now.

I'd also recommend you throw this in a file called watch_test.sh so all you need to do is type sh watch_test.sh. No need to remember the long command above.

If you find tests are too slow to watch continuously, consider fixing it. Tests should be fast.

• Tests that hit the network are slow, you could always add a skip flag to slow tests and test them individually later. Or even better, mock them out.
• Tests that hit the DB can be slow too, I'd recommend mocking that out too.

Enjoy

P.S - Credit to Warun K for inspiring this with his article here.

A lot of yUML users want to generate diagrams programatically. The best way to do this is by POSTing your DSL text to yUML. This overcomes the problem of too much text in your URL. Here's an example with curl:

curl -X POST -d "dsl_text=[Curl]->[Example]-.-[Nice{bg:wheat}]" https://yuml.me/diagram/scruffy/class/ 

This returns the filename with svg extension - e3c59524.svg

You can then download with whatever extension you like (svg, png, pdf, jpg, json) like this:

curl https://yuml.me/e3c59524.png --output test.png

And you'll get a diagram that looks like this:

A few tips

• For a non-scruffy diagram, POST to https://yuml.me/diagram/plain/class/ or https://yuml.me/diagram/nofunky/class/
• Your DSL should be comma separated, e.g. [Curl]->[Example]-.-[Nice{bg:wheat}],[Curl]-[Stuff]
• You can register with yUML to created named diagrams with permalinks. We haven't tested POSTing diagrams in this way for that yet.

Enjoy!

Our wise previous Scrum Master, Dave Taylor, asked on LinkedIn:

Thoughts on teams/orgs that have already tried scrum but not found it useful. I’m always curious to understand which parts they didn’t like or find relevant to them - quite often we’ll discover that it’s things that are not actually Scrum anyway.

It's a great question. Dave taught me a lot about Scrum and was one of the few people I've met that seems to understand it. At least as far as I can tell, as I don't :)

I personally think pretty much all of Scrum is useful. IMO, the one thing I really don't like about Scrum is that it's REALLY REALLY HARD to implement! And the Scrum Guide seems to only lay out a basic foundation, then you're on your own.

Here's the things I've personally found hard to achieve at Pocketworks. It's not that this stuff isn't useful, it's just that it's hard to implement.

DISCLAIMER: I'm not Scrum certified and might not understand some of this stuff!

So, what's so hard about Scrum?

Org Change

It often needs profound changes in attitude and business structure. Doing it properly probably means changing many aspects of your software business. That includes leadership, organisational structure, management styles, recruitment and promotions. This is a LOT to ask.

Cultural Change

To make it worse, if your company doesn't align with the scrum values, you're going to struggle. Cultural change isn't easy. Àgain, it's a lot to ask of a business.

Training

Because the concepts require quite a shift from traditional thinking, they're hard for people to accept, grasp and then live by. So training isn't easy. It requires a mind-shift. Training people on any kind of business process can be hard.

If you don't believe me, look at how many certified Scrum Masters are asked to perform project-management duties. Or look at how many Product Owners don't have the final say. Or how many Scrum development teams are downstream of separate UX/design teams. None of this would be happening if training Scrum was easy.

Cross-functional Teams

Scrum encourages forming teams that can create a shippable increment. This means having a mixture of designers, developers etc on the same team. Many companies find it easier to silo teams into different departments. So you have your iOS team, or your Design Team. These are then dependent on external teams to ship an increment. In some situations, this might mean org restructuring. Not for the faint hearted!

No Hand-overs

It feels logical to introduce things like "Design Sign Off" or "Peer Review". But Scrum encourages us remove stage gates in order to increase speed. That's counter-intuitive sometimes, you'd assume people with similar skills want to sit together. But instead, Scrum advocates usually encourage arranging people around the work.

No Team Heirarchy

Most companies want their Senior Developer, Lead UX or Architect roles. The idea that certain experienced people get the final say. Scrum doesn't recognise or encourage such heirarchy. But if you do that you're basically saying "This person has less autonomy and responsibility than the other". Scrum pushes for self-organising teams, which means they may elect to distribute such responsibilities amongst themselves, but not as mandated by the wider business.

Regular Stakeholder Feedback

Scrum advocates a series of feedback loops. One of these is that end-users and stakeholders should review the software every increment. Getting everyone in a room every few weeks is hard. Basically, people are busy, and they have to prioritise reiewing the software otherwise those reviews don't happen, which ultimatley means you're missing a key ingredient of Scrum.

And imagine this in a bank, where people are used to status reports and hands-off milestone tracking. None of that. If you want to see where stuff is at, go look at it.

Shippable Increments

Similarly, Scrum recommends that every week we have a potentially shippable increment of a product every Sprint. This is really hard because teams then have to take time to figure out how to slice the work up so that they can ship something in the sprint. It's easier just to crack on and hope for the best. So everyone has to appreciate the value of always-shippable.

Product Owner as Final Decision Maker

I've rarely heard about this being the case. The Product Owner is supposed to be a CEO of the product, managing profit and loss, budgets, performance, vision etc. But in reality PO's tend to end up being more like project managers where other teams or executives call the shots.

Terminology

People often Scrum requires things that it doesn't. None of these are part of Scrum...

• Story Points
• Stories
• Velocity
• Demos
• Refinement as-a Meeting (it's ongoing)

Story Points

"5 points is a day's work for our team". You hear this kind of crap all the time. Although points aren't even part of Scrum, it's so annoying how people still do this and associate it with Scrum. I spoke to a CEO last week who said "My team said they can do 1.5 points a day, and I told them they needed to buckle down and do 2 points a day". It's not his fault. It's just hard. I spent ten minutes trying to explain it and he still didn't get it. They're an awesome tool but few can get to grips with them and they end up being misused.

Thoughts welcome.

As a managing director, I hit problems in business on a weekly basis. Business just throws crap at you all the time. Then, you have to figure out what to do about it.

Here are a few examples of crap that hit me over that last 5 years:

• We’ve accidentally done £150,000 worth of work which we can’t invoice the client for because we didn’t have tell them we were doing it. Shit!
• We haven’t sold anything this quarter, how are we going to pay the bills?
• We’ve just gone over budget for the second time and the client is going to ditch us.

I used to just deal with problems like this in the moment. I’d figure out a solution and deal with it case-by-case. You can always find a way to get by, right?

The problem with this is that you don’t really fix anything. Problems happen again and again and again. And this means your business or department is going to be a pain in the backside to run. You’ll have less fun and more stress.

The good news is that, over time, I’ve learned a simple method for dealing with this kind of crap properly. A method that means it’s much less likely to happen again. So what is it?

“Make it visible.“

I could also have worded this as “Expose the data” or “Map it out” or “If you can’t see it, you can’t solve it”.

In my view, almost any recurring business problem can be improved by increasing your visibility of the problem. The idea is simple:

1. Determine what data is relevant to the problem
2. Capture the data, building a picture of the data in a way that gives you some insight
3. Create a way of updating and reviewing this regularly

So, if you’re over-servicing a client, the solution might be:

1. Record time spent on the client
2. Create a report of time against budget
3. Do this every week, and review

If there’s a problem, you can see it coming and deal with it before it escalates.

This is incredibly simple. Don’t let that put you off - it’s powerful too.

The trick is to approach problems thinking “What can we not see that allowed this to happen?”. You’ll soon realise that your business problems are often due to lack of visibility.

Your job is to create visibility.

Another upside is how you interpret what others say. So, when you’re in a meeting discussing a new load of crap that’s hit you out of nowhere, you’ll hear people propose solutions. Then, you’ll start categorising them in one of these two ways:

• Is it a solution that masks the root cause to get us through the day?
• Is it a solution that addresses the root cause so the problem is properly fixed?

You’ll start to favour solutions that consider the relevant information and which attack the root cause. And if the facts aren’t known, you’ll look for ways to reveal them so that your solution quality goes up.

Some of you might dismiss all this advice because you’re thinking “This is too obvious” or “I don’t have time or motivation for this”.

This is how I used to think too. And if you think like this, you have work to do. You need to have a hard think about why you don’t want to fix your own problems properly.

The thing is, how else can you do it? How do you expect to solve your business problems if you don’t a) look at them more closely and b) making that a repeatable thing?

Doing both of these things means you go from reactive to proactive. This is what allows the problem to stop happening.

Hope this helps!

P.S - If you're a software developer, this should work for you too. E.g. Tearing your hair out on a code base that's hard to change? You probably can't see the execution paths. What's the smartest way to make execution paths visible? Then you can look at simplifying them with refactoring. What can you do to make this complexity more visible on a regular basis?

I decided to invest some time improving my blog. It was feeling like an out-of-date, tired old place that gave me no inspiration to write. So, you’re now seeing the new, faster version that should work nicely on phones and tablets, and also be more readable with better structure.

Renders nicely on the iPhone 11 Pro

Here're the results from Google Page Speed.

Speed test is reasonable :)

Why roll-your-own?

I considered writing on Medium before doing this update. But I don’t like the idea of someone else having control of my content. Or blocking people from reading it unless they pay. I enjoy Medium but hate the paywall.

Secondly, I’ve got lots of old posts on here. I thought about starting afresh but there’s something nice about keeping the history. That content still gets read today, so why throw it away?

I also considered the Ghost platform, which looks awesome. I decided against it once I’d reminded myself how easy Sinatra is to work with. Switching to Ghost would have meant having to import all my old content.

Bulma, Sinatra, Lazy Loading etc

Updating it wasn’t as bad as I’d feared. A re-skin and a few other improvements took only 4 hours.

This site was an incredible simple Sinatra site. The guts of the site are only 250 lines of code, and that includes post authoring CMS, tagging, archiving and RSS feed generation. The hardest part of working with it again was updating the dependencies, some which date back to 2008.

So, I decided to have a crack at modernising it, which basically meant updating to newer versions of Sinatra and Ruby, retiring the old CSS and trying out Bulma.io. I also applied some new typography, some lazy image loading and simplified the navigation. This meant it was mobile-friendly, faster to load and more readable.

I picked Bulma because I fancied trying something lighter than Bootstrap. Bulma seemed a little simpler. After 4 hours of use, I'm starting to get the hang of it. Instead of customising using it's npm package or webpack, I just monkey-patched the CSS. When I get more time I'd like to come back and customise it properly. Feels a bit hacky!

Cloudinary

If you look at old posts you'll notice lots of images are broken. I was using http://puush.me in the past, but for some reason, my images have gone. I considered a few new places to put the images.

• S3
• DropBox
• Cloudinary

Amazon S3 was my first thought for images. I could whack a CDN in front and all would be good. Unfortunately I couldn't find the login, and since everyone at work is on holiday couldn't easily find out.

Dropbox was the next stop. It seemed pretty good to start with. Just upload to a public folder, preview online, then copy the preview image URL. I then hit issues with .webp images on Safari (they don't work) and realised I needed to convert to .jpg.

Finally, I realised that something like Cloudinary would do this for me, and was actually designed for developer image hosting. So, I dragged the images up to there where there are a load of optimisation options available for a blog like this. I think the free account will do nicely for a while, so that's a bonus.

Cloudinary is really easy to use and has great features for blogs

So, hope you enjoy the new blog. There are a few niggles to fix so I’ll get to those as I go.

Here’s the old site, in case you haven’t seen it. It’s also available on wayback machine.

The old design of this site

I donated my iPad Pro to the office back in September. I had a 12.9-inch first-generation model from 2015.

A few months later and I am missing it badly. For one reason only - sketching.

I mostly used the iPad Pro for sketching notes, mind maps, user personas, user interfaces, that kind of thing. Here's some examples drawn with the 53 Paper app.

A user persona sketched with 53 Paper

Some user flow ideas sketched with 53 Paper

The problem was, the first-generation iPad Pro is a big beast. It's too big and heavy for everyday use in my opinion. So, for me, I'd only use it a few times a month. I'd use my smaller and lighter iPad Air for reading and daily around-the-house stuff.

I think a person only needs one iPad. Nobody wants to carry two iPads around with them. If you don't use the 2nd one very often, you forget to charge it, which means you can't use it when you want to. And then you have the hassle of running software updates twice.

If you're the sketching type, you should have one iPad that supports the Apple Pencil. Fortunately, in 2019 all iPads support the Apple Pencil. The iPad, iPad Air, iPad Mini and iPad Pro. The question is then, which pencil should you buy? First-generation or second-generation?

The newer Apple Pencil is better. It has an extra touch-sensitive sensor that you can tap to switch tools. It's also magnetic, so clips nicely to the side of the iPad when charging. Much better than the goofy Lighting connector setup seen on the first-generation Apple Pencil. If you're a serious sketcher who can afford £1,000, then the Pro is the sensible option because this is the only one that supports the new Pencil.

The iPad Pro with Keyboard and Pencil will cost about £1,067

In the near future, I'll be selling my old iPad Air and getting a new iPad Pro. Having not had one for a few months I really miss being able to visually throw ideas down. Having one iPad will simplify things a little. And I'll go for the smaller size so it's easier to carry around.

Think this is the right choice?

There’s been some interesting debate on Twitter around working long hours. Jason Fried from Basecamp argue this:

If your company requires you to work nights and weekends, your company is broken. This is a managerial problem, not your problem. This is a process problem, not a personal problem. This is an ownership problem, not an individual problem.

See the Twitter Thread

I’m a big believer in standard working hours. So much that It's part of the business plan for Pocketworks in terms of our financial model and the culture we encourage. I chose this view after learning from a few sources:

1. The agile community
2. Personal productivity coaches

The agile community generally discourage mandatory overtime. Decades ago, Kent Beck came up with the notion of sustainable pace as part of Extreme Programming. This meant getting things done in the confines of a 30-40 hour working week. The idea is that teams learn to deliver software for the long-term without the team burning out or losing motivation.

This recognises that overtime is an anti-pattern because it can be used as a quick-fix for schedule, management or quality issues. If you hide the underlying issues, it’s very hard to fix them. In other words, you can’t fix what you can’t see.

Overtime also trips up your velocity. Velocity is a useful metric because teams can use it to forecast when things might be done. Ad-hoc over time will make it hard to achieve a stable velocity, which means you’re not going to be very predictable. Nor will you be able to be repeatable. Your performance each month will vary wildly.

Predictability and repeatability are good things to have in business.

Another angle is around personal growth. If you work late every day when will have time to develop your own skills by learning and practising?

Coaches such as Brian Tracey, Tim Ferris and Stephen Covey advise that we become disciplined enough not to take our work home with us. If you’re itching to do something productive instead of watching Netflix, use your own time for personal development and learning. In my view, it’s not “work” as long as it’s fun, entertaining and not stressful. For example, practising a new skill is generally fun, and you can break off to read a book or see friends whenever you want. That’s very different to work.

As someone who runs a business, I still work to this rule today. I use my free time to help my own development. Sometimes I practice techniques and ideas around real work, but most of the time I don’t want my personal experiments interfering with work deadlines and stresses because that can take the fun and motivation out of learning.

In short. If you’re a tech manager, give your business a chance at being sustainable by eliminating long hours or overtime. And when you do want to work out-of-hours, work on your own skills and education. Try not to mix this with your day job too much, otherwise, learning can become stressful.

Thanks to this, there is a nice tool to allow creating of yUML diagrams from the command line or scripts.

For example:

$ echo "[Hello]->[Tobin]" | yuml -s scruffy -o diagram.png
$ open diagram.png

Which opens this

To install this cool tool on your Mac, just do this:

$ sudo easy_install pip
$ sudo pip install https://github.com/wandernauta/yuml/zipball/master

That's it, you're DONE!

There are over 194M photos taken with an iPhone on Flickr. In comparison, the popular Samsung Android phones have around 11M photos.

That's quite a staggering difference.

For stats... see the iPhone 5 on Flickr, and also the Galaxy S4 on Flickr here.

Both platforms are awesome

My sister is looking for a new smartphone with great photo and video capabilities. I was checking out how the leading Apple and Samsung phones compared.

iPhone 5 shots

Galaxy S4 shots

Both take amazing pictures in my opinion.

I also love that users are enhancing their photos with interesting effects. Apps like SnapSeed, Instagram, Flickr etc are making this easy. Too easy? Perhaps.

There are a lot of over-cooked photos on the web, but I think that these apps actively encourage people to keep taking pics, because they can get amazing results with little skill by applying some filters.

Here are a few more ramblings roughly on this topic:

Photographers are unusually quick to adopt the latest phone

It was also interesting to see the adoption of iPhone 5 climbing rapidly in the last year. Those Flickr users seem to upgrade quickly!

The Samsung Galaxy III adoption was equally fast over the Galaxy II.

I suspect photographers are a wealthy bunch who can afford to upgrade often :)

This doesn't fit what I'm seeing elsewhere. We have stats for all the apps we build at my company Pocketworks.

An example of an app that is used by a wide demographic in Leeds, UK.

So, Flick users are quick to adopt the latest and greatest in comparison the "regular" users I see. I wonder if Facebook will post similar stats anywhere...