mazzi.github.com

Building Microservices - The Platform Team

Tue, 19 Dec 2023 00:00:00 +0000

A beautiful section from Building Microservices from Sam Newman about The Platform Team.

Why exists? What’s the purpose?

A platform needs someone to run and manage it. These technology stacks can be complex enough to warrant some specific expertise. My concern, though, is that on occasion it can be too easy for platform teams to lose sight of why they exist.

Who is the stakeholder?

A platform team has users, in the same way that any other team has users. The users of the platform team are other developers—your job, if you are in a platform team, is to make their lives easier (this of course is the job of any enabling team). That means that the platform you create needs to fit the needs of the teams using it. It also means that you need to work with the teams using your platform not only to help them use it well but also to take on board their feedback and requirements to improve the platform you deliver.

Thinking more widely about other ways to make developers’ lives easier.

In the past, I’ve preferred calling such a team something like “delivery services” or “delivery support” to better articulate its goal. Really, the job of a platform team isn’t to build a platform; it’s to make developing and shipping functionality easy. Building a platform is just one way that the members of a platform team can achieve this. I do worry that by calling themselves a platform team they will see all problems as things that can and should be solved by the platform, rather than thinking more widely about other ways to make developers’ lives easier.

Enabling team. Build bridges, not walls.

Like any good enabling team, a platform team needs to operate almost like an internal consultancy to some extent. If you are in a platform team, you need to be going out to find out what problems people are facing and working with them to help them get these problems fixed. But as you also end up building the platform too, you need to have a heavy dose of product development work in there as well. In fact, taking a product development approach to how you build out your platform is a great idea and could be a great place to help grow new product owners.

Hubs and Wheels

Sat, 10 Apr 2021 00:00:00 +0000

Surprised about the quality of the Shimano hubs. With hubs cones and bearings cleaned and assembled, I have the feeling that they run smotther than the Campagnolos from the same era. Changed the bearings for new ones. They seem to run forever.

More diagrams from the Shimano website.

The wheels look aligned. Until the last stage of the build, I will keep the Vittoria tyres to move the bike around. Nevertheless, pretty hard to get new tyres online nowadays. Looking for new 700x23c gum wall.

~~Hubs and bearings~~

~~Tyres + alignment~~

Got a new set of long allen keys to dissasemble the cockpit. Pretty nice system from Shimano to hide bolts.

Next step: Cockpit & Headset. Probably the last dirty job until I decided if I dive into the bottom bracket or not.

Checklist

Frame:

Seat & Seatpost
Cockpit
Headset
Frame itself

Transmission:

Bottom Bracket (?)
Crankset (x_x)
Pedals (x_x)

First batch ready

Mon, 01 Mar 2021 00:00:00 +0000

A couple of weeks had passed since I decided to start with the dissasemble of the PR-5000. This is the first update.

No many surprises so far: seatpost and stem are not stuck; Shimano 600 tricolor groupset complete (not sure about the bottom bracket yet); original Panasonic bottle cage. Didn’t check the wheels so far (they are Atala).

Started by dissasembling brakes (beatiful I must say), cables and the transmission. They are already dissasembled/degreased, cleaned, assembled/greased again. Same with the cable housings. I got a new set of cables (transmission/brakes) that they were totally destroyed.

~~Front/Rear~~

~~Cables/Housing~~

~~Rear derallieur~~

~~Front derallieur~~

~~Cables & levers~~

~~Chain~~

~~Cog~~

Pretty useful the Shimano website to find all the parts and pieces of each component. In this case, the rear derallieur

I was not able to take out the pedals. They are pretty stuck and I don’t have enough leverage with my tools. I’ll see what I can do. Same with crackset.

The brake handles rubber housings were removed. They were pretty dirty, but a good clean up with detergent made the first part of the job. Next one will be with CIF. Pretty good for rubber. I’ve tried to get replacements, but they are really hard to find and specially in white.

Next stop: probably the wheelset to check aligment, cones, bearigns, inner tubes and tyres. That could be a couple of mornings (need to go out and cycle too).

Checklist

Wheelset:

Hubs and bearings
Tyres + alignment

Frame:

Seat & Seatpost
Cockpit
Frame itself

Transmission:

Bottom Bracket (?)
Crankset (x_x)
Pedals (x_x)

Panasonic PR 5000 project

Sun, 14 Feb 2021 00:00:00 +0000

Just got my hands on a beautiful Panasonic PR-5000 (size 56). So far seems 100% original. Complete Shimano 600 tricolor groupset, Araya black rims and Turbo saddle.

The tubing is Tange Cr-Mo. The body has some stickers and seems that was bought on a German speaking store called “Marty”. In the front tube has a serial number engraved. Nothing on the bottom bracket. Also has a registration number in the seatpost. I wander how this bike arrived to Spain.

Looks like “PR” stands for Professional Racing. Here’s the team with the PR-6000.

I’ve decided to write a bit to keep a log on the steps that I will take to bring it back in good shape.

After restoring, I’ll sell it (If I don’t fall in love with it).

Checklist

Wheelset:

Hubs and bearings
Tyres + alignment

Frame:

Seat & Seatpost
Cockpit
Frame itself

Transmission:

Rear derallieur
Front derallieur
Cables & levers
Chain
Cog
Bottom Bracket
Crankset
Pedals

Brakes:

Front/Rear
Cables/Housing

Even found how they were made in Japan. High tech stuff!

Peter Drucker quotes

Wed, 01 May 2019 00:00:00 +0000

Peter Ferdinand Drucker was an Austrian-born American management consultant, educator, and author, whose writings contributed to the philosophical and practical foundations of the modern business corporation.

Here 10 quotes to keep in mind regularly.

Doing the right thing is more important than doing the thing right.

If you want something new, you have to stop doing something old.

There is nothing quite so useless as doing with great efficiency something that should not be done at all.

What gets measured gets improved.

Results are gained by exploiting opportunities, not by solving problems.

So much of what we call management consists of making it difficult for people to work.

People who don’t take risks generally make about two big mistakes a year. People who do take riswks generally make about two big mistakes a year.

Meetings are by definition a concession to a deficient organization. For one either meets or one works. One cannot do both at the same time.

Long-range planning does not deal with the future decissions, but with the future of present decissions.

Management is doing things right. Leadership is doing the right things.

Twelve arguments to sneak in features

Fri, 01 Feb 2019 00:00:00 +0000

When your product gets traction, you’ll nd yourself inundated with good ideas for features. These will come from your customers, your colleagues, and yourself. Because they’re good ideas, there will always be lots of reasons to say yes to them. Here’s 12 arguments that are commonly used to sneak features into a product:

But the data looks good
But it’ll only take a few minutes
But this customer is about to quit
But we can just make it optional
But my cousin’s neighbour said…
But we’ve nothing else planned
But we’re supposed to be allowed to work on whatever we want
But 713,000 people want it
But our competitors already have it
But if we don’t build it, someone else will
But the boss really wants it
But this could be “the one”

Extract from “Intercom on Product Management”.

An acid test for new features

Fri, 01 Feb 2019 00:00:00 +0000

Here’s a simple set of Yes/No questions that you can quickly answer before you add another feature to your product roadmap.

Does it fit your vision?
Will it still matter in 5 years?
Will everyone beneffit from it?
Will it improve, complement or innovate on the existing workfow?
Does it grow the business?
Will it generate new meaningful engagement?
If it succeeds, can we support and afford it?

Ben Horowitz's on Good and Bad Product Managers

Thu, 13 Dec 2018 00:00:00 +0000

Good product managers know the market, the product, the product line and the competition extremely well and operate from a strong basis of knowledge and confidence. Is the CEO of the product. Takes full responsibility and measures themselves in terms of the success of the product. They are responsible for right product/right time and all that entails. A good product manager knows the context going in (the company, our revenue funding, competition, etc.), and they take responsibility for devising and executing a winning plan (no excuses).

Bad product managers have lots of excuses. Not enough funding, the engineering manager is an idiot, Microsoft has 11 times as many engineers working on it, I’m overworked, I don’t get enough direction. Barksdale doesn’t make these kinds of excuses and neither should the CEO of a product.

Good product managers don’t get all of their time sucked up by the various organizations that must work together to deliver right product right time. They don’t take all the product team minutes, they don’t project manage the various functions, they are not gophers for engineering. They are not part of the product team; they manage the product team. Engineering teams don’t consider Good Product Managers a “marketing resource.” Good product managers are the marketing counterpart of the engineering manager. They crisply define the target, the what (as opposed to the how) and manage the delivery of the what. Bad product managers feel best about themselves when they figure out how. Good product managers communicate crisply to engineering in writing as well as verbally. They don’t give direction informally but they gather information informally.

Good product managers create leveragable collateral, FAQs, presentations, white papers. Bad product managers complain that they spend all day answering questions for the sales force and are swamped. Good product managers anticipate the serious product flaws and build real solutions. Bad product managers put out fires all day. Good product managers take written positions on important issues (competitive silver bullets, tough architectural choices, tough product decisions, markets to attack or yield). Bad product managers voice their opinion verbally and lament that the “powers that be” won’t let it happen. Once bad product managers fail, they point out that they predicted they would fail.

Good product managers focus the team on revenue and customers. Bad product managers focus team on how many features Microsoft is building. Good product managers define good products that can be executed with a strong effort. Bad product managers define good products that can’t be executed or let engineering build whatever they want (i.e. solve the hardest problem).

Good product managers think in terms of delivering superior value to the market place during inbound planning and achieving market share and revenue goals during outbound. Bad product managers get very confused about the differences amongst delivering value, matching competitive features, pricing, and ubiquity. Good product managers decompose problems. Bad product managers combine all problems into one.

Good product managers think about the story they want written by the press. Bad product managers think about covering every feature and being really technically accurate with the press. Good product managers ask the press questions. Bad product managers answer any press question. Good product managers assume press and analyst people are really smart. Bad product managers assume that press and analysts are dumb because they don’t understand the difference between “push” and “simulated push.”

Good product managers err on the side of clarity vs. explaining the obvious. Bad product managers never explain the obvious. Good product managers define their job and their success. Bad product managers constantly want to be told what to do.

Good product managers send their status reports in on time every week, because they are disciplined. Bad product managers forget to send in their status reports on time, because they don’t value discipline.

PoC RoR React and CSV

Tue, 07 Aug 2018 00:00:00 +0000

Has been a while without writing a technical post. Looking at startups I see often a webstack made out of Ruby on Rails (RoR) and React. With the facilities that RoR gives to create a REST API and the popularity of React, I understand the reasons.

To make a small PoC, I decided to import a random CSV to sqlite3 (why bother to use mysql/postgres for this example right?) so I can build a small backend with a service to find information easily.

Let’s start bottom up.

Model creation and importing the data

Download from this url the file 2019_domicilis_sexe.csv. It’s open data from Barcelona, identifiying “Homes of the city of Barcelona according to the sex of the people who live in them.” It’s just an example. Any other CSV file should be good as well, but you’ll need to change the mapping of the fields and the types.

How to import this data into sqlite3 using Rails, and seeds?

Copy 2019_domicilis_sexe.csv into ./lib/seeds/ directory (if not exists create it)

Modify ./db/seeds.rb and add the following code

 require 'csv'

 csv_text = File.read(Rails.root.join('lib', 'seeds', '2019_domicilis_sexe.csv'))
 csv = CSV.parse(csv_text, :headers => true, :encoding => 'ISO-8859-1')
 csv.each do |row|
     sd = SexDatum.new
     sd.year = row['Any']
     sd.district_code = row['Codi_districte']
     sd.district_name = row['Nom_districte']
     sd.neighbourhood_code = row['Codi_barri']
     sd.neighbourhood_name = row['Nom_barri']
     sd.sex = row['Sexe']
     sd.number = row['Nombre']
        
     sd.save
     puts "Entry saved"
 end

Let’s create the model for this table using: rails g model SexData year:integer district_code district_name neighbourhood_code:integer neighbourhood_name sex number:integer By default Rails uses strings as type for db fields. Just be explicit on integers on this case.
If the model was successfully created, you should see ./app/models/sex_datum.rb on your filesystem. A migration then, should be executed for the creation of the table: rake db:migrate.
Now with the model, the csv data and the seeds, let’s import the data: rake db:seed
To check that the model was created and the data imported, let’s use rails console: rails c
Once there, let’s find records: SexDatum.all Check names, types and values. All set!

Writing the Controller and handling the routes

Let’s create the namespace for the routes, so we can handle versions in the future.

Create the directory ./controllers/api/v1/

And the file sex_datum_controller.rb in the same directory containing two methods: one to return all the records (just a test) and another one that will filter records by district_code (as an example)

 class Api::V1::SexDatumController < ApplicationController
     def index
         render json: SexDatum.all
     end

     def show
         datum = SexDatum.where district_code:params[:id]
         render json: datum
     end
 end

Rewrite the contents (asumming that we have a project from scratch) of routes.rb so we can hit two urls http://localhost:3000/ and http://localhost:3000/api/v1/sex_datum/2. The number 2 is the district_code and is just an example.
```
 Rails.application.routes.draw do
     namespace :api do 
         namespace :v1 do 
             resources :sex_datum, only: [:index, :show]
         end 
     end 
     root to: 'home#index'
 end
```

Writing the View in React.js

An empty file should be created in ./app/views/home/index.html.erb. This file should act as a placeholder. The real content will be on ./app/javascript/components/App.jsx served by webpack. Remember to install the gem and configure the path on webpacker.yml (sorry, maybe a long topic for the same post) The tile App.jsx will have the following content:
```
 import React from 'react'
 import InputDistrictCode from './InputDistrictCode'

 const App = () => {
     return (
         <div>
             Hello, I am a react component rendered via rails webpacker
             <InputDistrictCode />
         </div>
     )
 }
 export default App
```

Now defining InputDistrictCode.jsx

 import React, {Component} from 'react';
 import Result from './Result';

 class InputDistrictCode extends Component {

     state = {
         code : '',
         result : [],
     }

     handleClick = (event) => {
         event.preventDefault();
         fetch(`http://localhost:3000/api/v1/sex_datum/${this.state.code}`)
             .then(response => response.json())
             .then(data => this.setState( {result : data}))
     }

     handleChange = (event) => {
         const {name, value} = event.target
         this.setState({ [name] : value })
     }

     render() {
         return(
             <div>
                 <input
                     name='code'
                     onChange={this.handleChange}>
                 </input>
                 <button
                     onClick={this.handleClick}>
                     Find it
                 </button>
                 <Result
                     data={this.state.result} />
             </div>
         )
     }
 }

 export default InputDistrictCode;

And the last component, Result.jsx

 import React from 'react'

 const Result = ({data}) => (
     <>
         {data.map( item => (
             <div key={item.id}>
             {item.district_name} - {item.id}
             </div>))}
     </>
 )

 export default Result;

Run the rails server with rails s and the webpack sever ./bin/webpack-dev-server. Heading now to http://localhost:3000/ you should see something like this:

Writing an integer in the input field and then hitting the button, some results from the database will be retrieved.

Hope it helps! If you need the code let me know in the comments.

Deploying node

Wed, 29 Jan 2014 00:00:00 +0000

All good. You wrote your first node app using express as your web application framework and everything looks amazing locally. Now the big question: how we deploy this live?

First of all, I had to do it in a DigitalOcean VPS using Ubuntu 12.04 TLS, so my first idea was to install node using apt-get install nodejs. No problems at all, except that was an extremely old version. Node ecosystem is changing day by day so if you are not aware of that you can end with an edge version in development and a stable in production. To get then the latest version, I suggest to use Chris Lea’s repository

$ sudo apt-get install python-software-properties
$ sudo apt-add-repository ppa:chris-lea/node.js
$ sudo apt-get update
$ sudo apt-get install nodejs

So far, so good. Next will be install npm, the node package manager with apt-get install npm.

Your node + express app will have a package.json file with all the project dependencies. In a good day doing npm install in your project root folder will be enough. npm on ubuntu has a differnt way to handle source repositories, so to be able to download all the dependencies we need to change an npm configuration setting.

npm config set registry http://registry.npmjs.org

The above command will tell npm were to go to download dependencies then. Re-executing npm install will download then all the dependencies.

Fair enough. Our application will be running without problems at this point. Now is time to configure nginx to serve the app.

When using node + express, executing node app.js in the project root folder will be enough to server the app in http://localhost:3000. Now we need to do the same but as a service in our Ubuntu box. For this task I’ve used upstart. Creating an file /etc/init/myapp.conf with the following content will do the trick.

description     "My Express App"

env HOME=/var/www/myexpressapp

start on runlevel [2345]
stop on runlevel [!2345]

respawn

env NODE_ENV=production
exec start-stop-daemon --start --umask 000 --exec /usr/bin/node -- /var/www/myexpressapp/app.js >>/var/log/myexpressapp.sys.log

It’s important to execute env NODE_ENV=production so the express app is able to run in production with different setting than development. In some upstart versions this command is not compatible. Excecuting then service myapp start will start the service.

Finally, we can create a virtual host in nginx to serve the app to the ouside world in a good way.

upstream nodejs {
      server 127.0.0.1:3000 max_fails=0; 
} 
server { 
  server_name mynodeapp.com; 

  add_header Strict-Transport-Security max-age=500; 

  location / { 
    proxy_pass  http://nodejs; 
    proxy_redirect off; 
    proxy_set_header Host $host ; 
    proxy_set_header X-Real-IP $remote_addr ; 
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ; 
    proxy_set_header X-Forwarded-Proto https; 
  }     }

Like this, nginx is acting as a proxy with the express service. Do not forget to set up logs at nginx level to see what’s going on!