Posts

Generating swagger doc with copilot for undocumented rails app

Was taking a peek at how to do this and I took a stab. Checked out gitlab project, fired up copilot and then (after a few iterations) hit upon this prompt: create a yaml file in openapi3 format that describes the methods and signatures of the contollers/admin/applications_controller controller assumes host are prod.myapi.com and stagin.myapi.com that host the api add detailed descriptions in the summaryfields that explain edge cases and any important side effects. Include list of tables accessed by api endpoints in the description. Format list of tables like the following (tables => {table 1}, {table 2}). Don't include character ':' in summaries, titles, or descriptions and what I got was openapi: 3.0.0 info: title: Dashboard API (Accesses various resources) version: 1.0.0 servers: - url: https://prod.myapi.com description: Production server - url: https://staging.myapi.com description: Staging server paths: /dashboard/appli

A new video series "The User Experience"

I'm starting a new video series called The User Experience . Subscribe and comment to help guide the topics. Aside from prepared content, I will be hosting interactive experience to discuss and debate topics around customer centricity, user experience, and technology.

webxr with Babylonjs, A-frame/Threejs, and Unity

I've been working quite extensively on a webxr side project. Originally it was built with a-frame / threejs. You can take a look at it here at Immersive Idea . Recently I relized I was "fighting the framework" more than I was "getting things done". Originally, I chose a-frame because it was essentially a "no code" (well just html markup) way to build scenes. Additionally it's ECS framework was very well documented and easy to use. In an effort to broaden my perspective I started looking at alternatives (Unity with OpenXr, Babylonjs) as I was struggling to keep the pieces working together. This is my (slightly long) recap of my observations. A-Frame A-frame is wonderful...it is well documented, easy to use, and the community is super friendly and helpful. If I simplly wanted to render scenes in webxr with minimal ability to manipulate the environment, I wouldn't even think twice about using it.... Heck I still use it for quick m

MACH TEN Addendum: for companies wanting to use MACH platforms

The MACH Alliance is a consortium of ISVs and SIs that advocate for a particular approach when building/integrating modern platforms. One gap/misunderstanding I keep bumping into is the intent behind MACH. In general, it's a technosophical approach to how PLATFORMS are build, run, deployed, marketed, not really well suited for large organizations who are simply trying to USE these platforms. Therefor I propose a "MACH TEN" Addendum TEN is an acronym that adds some context to adopting MACH platforms to use in your organization. These are high level recommendations I enccourage folks to take into consideration before jumping under the bandwagon. :p Transparent Pricing and contracts are computable, if special terms are negotiated, that's OK, but I shouldn't have to tell you my budget before you tell me how much you cost How I integrate/use your platform is easy to find, I don't need special training, I can just RTFM and begin using your system

Scaling teams: Two strong oxen or 1024 chickens?

Seymore Cray was famously quoted as asking: "If you were plowing a field, which would you rather use: Two strong oxen or 1024 chickens?". While he was referring to the advantage of using a single processor solution over a massively parallel solution (which I happen to think he was wrong about) I'll steal this question to use in another context. Namely, when building teams to around technical solutions, you will almost always get a better solution if you use a limited number of smart, motivated, and experienced technical resources over a large number of folks who are inferior in one or more of those dimensions. In that regard, I think solving technical problems is a lot like plowing a field... it's actually difficult work that cannot be scaled by adding more low power resources. The problem isn't a scaling issue, it's a complexity issue. Controlling two strong ox and focusing their effort is a lot easier than trying to herd 1024 chickens. If you've

Now not to do identity management (read this nintendo) [from 2019]

Identity management is hard Just so everyone understands, I get this...having worked with connected devices and multiple phones/consoles/cars/headsets/speakers all cross linked to other devices and other accounts...I get it's HARD to maintain and/or associate the correct PERSON with the correct DEVICE with the correct ACCOUNT (note, those are all different things...I can have multiple bank accounts, accessible from multiple devices, and multiple people could share my account and/or device, but who can do what from what is difficult. Add kids and games and shit to the mix I'm not necessarily saying nintendo has done a poor job (no...scratch that...I'm saying they have)... what I'm really saying is that they have a particular demographic that makes identity and device management difficult...namely KIDS. Now, before all the single parents with one kid who had a nintendo DS once who claim this shit is super simple...and before the folks who can only afford for their

Composable Software Architecture

Toying with the concept of "Composable Architecture" I'm struck by how many folks get lost on the technology and staring at "how do other people do it?" instead of pivoting to think about "how might this help my business?". Time and time again I roll onto a client that is talking about microservices, API first design, Headless solutions, Cloud Native platforms, but have no idea why any of this might help thier business. Routinely I head "well this is how [netflix, amazon, fill in some other business name] does it, so we're going to replicate their success by doing what they do. Why this is flawed The logic behind this thinking is deeply flawed because it's presupposing that the technology architecture by itself makes the business successful. This is, in fact, backwards. Netflix didn't start with a microservices architecture, they started with (and appropriately so) a monolithic architecture. Why? Because their business