caindy

WSL2 container development with Moby

Building, pulling, pushing, and running containers is something many developers do often without even thinking. Most of my development over the past couple of years has been exclusively in a Linux environment, specifically WSL2.

Even prior to the recent licensing changes to Docker Desktop, I found myself increasingly as an engineer whose workflow didn't line up with my tools. I never used the GUI features. I never built Windows containers. I used kind or k3d instead of the Docker Kubernetes functionality. I never mounted the Windows filesystem into my containers. And I certainly didn't enjoy frequent downtime caused by updates for those features that I wasn't using. I wanted the container experience in my dev environment to match what I got on a server - just the runtime & tools.

That said, I still like shiny new (or not-so-new but I never see anyone use them

caindy

// link to competition: https://www.kaggle.com/c/whats-cooking/

//reference deelde with fsharp charting
#r "../packages/Deedle.1.2.4/lib/net40/Deedle.dll"
#r "../packages/FSharp.Charting.0.90.12/lib/net40/FSharp.Charting.dll"
#I "../packages/FSharp.Charting.0.90.12"
#load "FSharp.Charting.fsx"
#r "../packages/Newtonsoft.Json.7.0.1/lib/net45/Newtonsoft.Json.dll"

open System

caindy

A comparison of Collection+JSON, HAL, JSON-LD and SIREN media types.

Discussion at 

http://sookocheff.com/posts/2014-03-11-on-choosing-a-hypermedia-format/

caindy

Make it real

Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.

Ship it

Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.

Do it with style

caindy

Please check this draft: https://medium.com/software-craftsmanship/9e8f0b85e9?kme=collabEmail.clicked&km_postIds=9e8f0b85e9

You should read about hypermedia APIs, if only to challenge your thinking. It helped me a lot to do just that.

Articles

• How to GET a cup of coffee http://www.infoq.com/articles/webber-rest-workflow
• My Week With The Hypermedia Cowboys: http://wekeroad.com/2012/03/13/my-week-with-the-hypermedia-cowboy, http://wekeroad.com/2012/03/18/alt-tekpub-consuming-the-api, http://wekeroad.com/2012/03/22/alt-tekpub-working-more-with-the-hypermedia-style-api, http://wekeroad.com/2012/03/26/loading-data-from-the-api-how-much-is-too-much
• How much rest should your web api get http://blog.restlet.com/2013/05/02/how-much-rest-should-your-web-api-get/
• How I learned to stop worrying and love REST http://mikemayo.org/2012/how-i-learned-to-stop-worrying-and-love-rest/

caindy

For example, one of the many current day standards that was dismissed immediately is the WWW (one could hardly imagine more of a mess).

But the functionality plus more can be replaced in our "ideal world" with encapsulated confined migratory VMs ("Internet objects") as a kind of next version of Gerry Popek's LOCUS.

The browser and other storage confusions are all replaced by the simple idea of separating out the safe objects from the various modes one uses to send and receive them. This covers files, email, web browsing, search engines, etc. What is left in this model is just a UI that can integrate the visual etc., outputs from the various encapsulated VMs, and send them events to react to. (The original browser folks missed that a scalable browser is more like a kernel OS than an App)

These are old ideas, but the vendors etc didn't get it ...