Friday, November 23, 2018

Solution first, Product second

You can't just write a "Framework", so can you just write a "Product"?

Lots of frameworks exist that look great, until you start using them. Soon you find the model the author has in their head doesn't match the reality you are facing, and the impedance mismatch leads to confusing work around and 'cludges'.

The right approach...

Write your app. Keep concerned separated so you make a conscious decision with each piece of code "Is this part of my domain? Is this extending the language? Is this just integration code?". Build your language so your domain code is clear and expressive. (As a hint... any code that uses Generics should be extending your programming language, not your domain.)

Then when you are done... write another app that's similar. When doing this you will copy the bits that worked from the last one, and throw away the things that didn't work out.

Then you do it again!

...and again.

Eventually you have a toolkit of things that you keep copying from project to project. That's your framework. It makes design compromises in the places that don't matter to remain flexible in all the places that do matter. For each product you can use the bits you need and discard the rest.

That's why frameworks frequently come out of consulting companies. Consultants work with lots of companies solving problems in different domains, but hitting the same technical problems over and over. "Man we did this in the last project, do we really have to do it again?". Frameworks should solve these incidental problems so you can focus on the core domain.

What does this have to do with Products?

When developing a product you face the same problems. You solution may miss the point, or solve half a problem, or only work for 80% of the problem and make the rest impossible.

How do you build a product that completely solves a customer's problem? Not just work well enough that customer can be sold into buying it, but well enough that customers will go crazy for it. Gush to their friends about it. Bite your hand off if you try to take it away from them!

Feel the pain.

Pick a potential customer with a problem who is feeling enough pain that they will let you work alongside them in the hope you can help. If this customer is exemplar there should be lots of other potential customers should you provide enough value. Now embed yourself in their world until you too feel the pain.

Now solve a problem. 

Pick a problem. Start small. Quick win. Runs on the board. Low hanging fruit.  You get the point.

Then pick the next problem. Solve it. Repeat.

When you solve it.. truly solve it... don't stop until you see delight in the eyes of the user. When a problem is truly solved the pain goes away.

Sure, your customer will love you, but that's not the goal. You are building your understanding of the problems in their domain. Do this long enough and you will either solve a problem big enough that it changes how your customer works. If not, find another customer to help.

If you provide enough value, your customer will rave about you! Now point your raving advocate at as many people in their industry as you can.

Friday, March 09, 2018

Using Docker on a Remote Host: Why so hard?

I have a windows PC at work and an Ubuntu box which happens to be running dockerd.

I have the docker command installed on the windows box, but it occurred to me I should be able to run the command using the Ubuntu box as the host.

Challenge accepted.

After a bit of digging I find :

https://forums.docker.com/t/connect-to-remote-docker-host/13112
>docker -H 192.168.2.1:2357  xxx
should work.

no luck.. fails to connect...

On Ubuntu I run
> netstat | grep docker -i
and find the 2357 port is not open... so back to google.

Turns out you need to tell dockerd to open that socket.
You can do that from the commandline when running dockerd (with the -H flag)
>dockerd -H tpc://:2357

I have no idea where the command line is being run from, so I keep digging.
https://docs.docker.com/engine/admin/systemd/#start-the-docker-daemon

Turns out you can also configure this in a config file... daemon.json
https://docs.docker.com/engine/admin/#configure-the-docker-daemon

I don't need encryption as it's all on my local network.
I add in some hosts...

> sudo systemctl daemon-reload
sudo systemctl restart docker

https://docs.docker.com/engine/reference/commandline/dockerd// "

BIND DOCKER TO ANOTHER HOST/PORT OR A UNIX SOCKET

"

Bang..
https://github.com/moby/moby/issues/22339

Turns out the commandline is also adding hosts... so you can't do both.

I decide to add mine to the command line too and remove it from the json.
> sudo vi  /lib/systemd/system/docker.service

ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375 -H tcp://10.10.253.140:2377

the 0.0.0.0 didn't help... 
so I added my actual IP address... 

and that works. This isn't ideal for a few reasons. My IP address being dynamic being one.

This all took a couple of hours I won't get back, so I thought I would share.


GitHub Projects