matthewkmayer / matthewkmayer.github.io Goto Github PK

It's currently hard to know how to provide feedback to me on these blog posts. It'd be great to have a blurb on how to provide feedback on things that can be improved or fixed.

Ways of communicating:

• issues in this repo
• twitter
• email

Put this in the footer? Put something in each blog entry?

What's the line for "enough" testing?

What kind of testing? (Automated, of course, but what level? Unit, integration, functional, end to end/smoke?)

Antilock braking systems on a bike: helps when things go wrong. Gets better and better as tech moves on, so it's no longer true a professional rider on a closed course can out-brake ABS. Now, under perfect conditions, ABS and non-ABS are about equal.

But ABS really saves your bacon when things fall apart: surface debris, rider fatigue, distraction, etc...

Rust is like ABS: it's there to keep you from crashing when things don't go perfectly right.

From https://github.com/rusoto/rusoto/blob/master/CHANGELOG.md :

• six releases
• 23 new services
• five new regions
• Multiple enhancements to credential sourcing such as support for anonymous credentials and credential_process support
• all crates on Rust 2018 edition
• opt-in for being able to serialize and deserialize response structs
• lines of code: 861,974 at 9902607f5 and 866,283 at rusoto-v0.36.0. Reduction in lines of code despite above improvements!
• all clippy lints applied

git lg1 or GitKraken or something in a sample repo to demonstrate things.

What I'm looking for in a github repo in an applicant:

• show (working) example code
• have a link to a deployed example (made a cool game in the browser? show it off!)
• make the READMEs useful. Write for people who don't know what it is or why it's important, and make it concise
• show off build badges
• published docker containers are sweet and show knowledge of how you expect it to be used
• got a blog? make sure there's a link to it, no everybody knows how username.github.io is a public site

rusoto s3 example is a common Google search. Let's make a blog post showing how to do a variety of S3 actions with Rusoto.

Let's try https://github.com/tildeio/helix and make a walkthrough.

• review feedback from https://www.reddit.com/r/rust/comments/6c7xpp/walkthrough_rocket_diesel_and_a_postgres_database/
• use new version of Rusoto

Make rusoto/rusoto#599 a blog post.

A workflow for fixing bugs:

• reproduce the bug
• make a test for the bug
• push branch with just the failing test
• see build service fail the build
• fix bug, push new commit to branch
• see build service pass the build

Separate bug fix from the repro test for ease of code review and showing the test and fix work.

Broke some existing posts, dang!

Let's get an idea where Rusoto performance stands.

Benchmark ideas:

• how quick can 50,000 messages be sent?
• how quick can 50,000 messages be received?
• add threads/goroutines and redo tests

https://blog.rust-lang.org/2018/12/06/call-for-rust-2019-roadmap-blogposts.html wants more posts!

Ideas to kick around:

• Celebrate success: always pointing out ways to improve can be demotivating
• Compilation speed (very briefly, get it out of the way, everyone's tired of hearing that drum beat)
• XML parser: something working like serde-json would be 💯
• More cloud SDKs: Rusoto is great, we need GCP and Azure as well
• IDE and tooling for monorepos - IDEA Rust plugin and VSCode+Rust plugin don't handle things really well
• An updated post on how to improve compile times by avoiding pathological behavior

https://agilemanifesto.org/principles.html states:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Levels of support vary:

• very high level guidance for seniors
• control without micromanagement for juniors

Senior vs junior is not based off time in industry, but business and technical maturity level of the person. One can tell a senior person "our customers struggle to do $FOO" and they can come up with a solution that lets the business solve customer problems while making money. A junior person needs to be told what they will be doing, sometimes down to half-day increments, while they learn how to be autonomous.

Having the wrong level of support causes lots of friction: senior people will feel micromanaged and unable to perform at their top level. Juniors will feel lost and not know if they are doing the right thing or doing things right.

I thought this was fixed in a PR but apparently not. There's a command and awkward phrasing in the footer.

https://github.com/matthewkmayer/rusty-von-humboldt needs a Rusoto feature that isn't in a release yet. It also needs to cross-compile from OSX to Linux to run on AWS.

Make a walkthrough describing the problem and how to do it:

• cross-compiling openssl is painful
• Docker can't toss in a folder in a parent dir
• make a Dockerfile that brings in Rusoto from GitHub and creates a Linux binary we can use for deployment
• why this approach vs letting TravisCI do it

Take the pages of notes and have at a post

A pull request is a signal for feedback requested (http://scottchacon.com/2011/08/31/github-flow.html). They do not need to be a completed feature.

Small PRs are:

• easier to review
• allow short lived branches (trunk based development, no merge hell)
• easier to respond to feedback
• allow focus to remain on the task at hand instead of having multiple PRs for different tasks in flight

Large PRs:

• encourage rubber stamp approvals
• aren't empathetic to reviewers
• are more likely to have merge conflicts

Assumption: trunk based development (TBD) is superior to GitFlow or other SCM strategies with long lived branches.

GitHub Flow and Trunk Based Development: no hot patchin'!

Give insights into what's going on in Rusoto!

There was some refactoring work in Rusoto and now some links are broken, such as The generate_source function is defined in service_crategen/codegen/generator/mod.rs: .

Test-first development, functional tests, test early and often, etc..

• ECS Fargate
• ECS
• bake an AMI with Packer

Big ol' post on what I've found effective for software development.

Values like "build the right thing" and "build things right." Solve customer needs, tight feedback loops. Continuous improvement, continuous learning. Recovery from failure is more important than unattainable "failure is not an option."

Processes like continuous integration, which is not "running Jenkins." Trunk based development. Limit WIP. It's done when it's in prod, with tests, and monitoring, and feature-flagged on/is available. Automated tests to ensure correctness and enable higher velocity.

Tools like trunk based dev, fast builds, feature flags, information radiators (is the build green?), lunch and learns, investment days. Whiteboards as the best way to communicate.

Branching strategy to avoid merge conflicts matter even as a solo developer.

Example: CHANGELOG.md in Rusoto. If two branches are in flight the second one can have a merge conflict after the first is merged.

Compiling Rusoto on my old, low-spec Macbook is painful: 45-ish minutes to build integration tests, battery is worked hard, space is a concern, etc...

Let's compare options:

• using my desktop to build through VS Code
• cost of upgrading that desktop
• renting an EC2 server: cost for that?
• if we rent a server how do we keep costs from spiraling out of control? A lambda using Rusoto to ensure it's not running!

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html

https://aws.amazon.com/ec2/pricing/on-demand/

Blog post on these completely distinct concepts:

• build machine/build server
• CI
• CD

To fulfill rusoto/rusoto.github.io#118 let's make a full fledged example with https://aws.amazon.com/cdk/ .

CRUD with Dynamo?

Software will have mistakes that lead to bugs. How do you respond?

Choose to reduce mean time to repair (MTTR)?

Believe that with enough testing, all bugs can be caught, requiring extensive testing before any release?

(show examples of highly trained professionals that are the gold standard of software still have bugs in their code)

I've had people reach out who missed the AgilePDX Behavior Driven Development with Cucumber presentation and would like to learn more.

Convert https://github.com/matthewkmayer/talks/tree/master/bdd-cucumber into a blog post!

Probably a multi-parter but should be good!

Hi,

First, thanks for the postgres-tls-tester, it's the only working code I found for use in Rocket / Postgres / SSL.

I have trouble to disable the certificate verification in the last part of the code (when the connection pool is created), the code works on my dev machine with a self signed certificate, but I need to disable that certificate check for use with my DB provider (I only need the data to be encrypted).

I can disable that check when not using the r2d2 pool in some test programs, but I don't find anything to do this with the r2d2 pool, maybe you can help me ? :-)

Nicolas

Know your audience.

• future-others is different than future-you: others are looking for different things, value information density and generally want to get to the point fast.
• the delivery team wants different things than the general public.
• docs attempting to cover all audiences will do a poor job at all of them: devs/QA aren't happy, customers aren't happy

Write a post covering Rusoto's history of build services: single build to stable/beta/release channels to those channels plus OSX and Windows to current state of Azure Pipelines for our work.

Why make those changes, what benefits occurred when doing so, what went well, what's next.

Come up with a cohesive way of explaining:

• small tasks
• it's not "done" until it's in production
• limit work in progress
• working, delivered software now is better than perfect software sometime in the future
• frequent deployments mean deployments are less scary

Them: respect people's time.

• Just in time planning over comprehensive ticket/story documentation and requirements.
• Continuous integration over long lived branches to avoid throwing away work and taking too much of reviewer's time.
• Communicate enough, at the right times, over going dark for days/weeks/months.
• Write documentation with a communication goal in mind. See #64 .

Benchmark my Go weapon of choice vs a couple different Rust HTTP servers.

Go

https://github.com/gorilla/mux

Rocket

https://github.com/SergioBenitez/Rocket
https://github.com/diesel-rs/diesel

Shio

https://github.com/mehcode/shio-rs
https://github.com/diesel-rs/diesel

Benchmark

• hello world endpoints
• GET something from DB and return JSON
• POST JSON object payload to DB
• use https://github.com/rakyll/hey ?

Other topics to cover

• ease of coding
• compilation speed differences
• Rust nightly vs non-nightly

Crate review? An overview? A rewrite-it-more-better approach?

An incomplete list of things that should be addresses when making a real service should be addressed.

Review what we did in 2017!

List of resources for these topics:

• git
• branching strategies
• ruby
• go
• cucumber and bdd
• tdd
• cloud and aws
• professional development
• mentoring

https://hackernoon.com/aws-lambda-go-vs-node-js-performance-benchmark-1c8898341982 nicely shows why Go is such a boon over other languages in Lambda. This is where users that have high volume AWS functions could really save money when switching to Go, as their bill could effectively be cut by up to ~40%.

Can we recreate those benchmark, but compare Go and Rust? Does Rust and Rusoto beat Go?

What else is a win for Rust on AWS? Can we back up those claims with numbers and examples?

Taking a break from open source work in 2019! 🎉

Rough dates: April 2019 through October 2019.

Rusoto would benefit from another active maintainer. 👍 Currently about six people with maintainer rights.

Checklist for Rusoto-related advertising:

• publish this blog post
• make a tweet
• post to rust subreddit?

Needs:

• call out which version of Rusoto we're using
• inline code blocks aren't called out well. Try code fences (triple backticks) or gists.
• screenshots of various steps, including the final result
• default VPC really needed?
• explain Diesel code instead of glossing over everything but migrations
• explain Rocket code
• fix Rocket code to not do a new connection on every request (https://github.com/SergioBenitez/Rocket/blob/master/examples/raw_sqlite/src/main.rs)
• add links to Rusoto, Diesel and Rocket pages. Introduction paragraph maybe?
• Call out which version of Rust nightly used and how to use that version with rustup
• More details on the database interactions: clarify create_hit etc and what we're glossing over vs incrementing/using.

Make a blag post series of building Rusty von Humboldt. Audience: folks wanting to know how to use basic S3 examples, parallelization examples and usage of the flate2 crate.

• Skeleton and downloading a file from S3
• Parse JSON file from S3
• Multi-threading with MPSC and Rayon
• Emit SQL, compress it, upload to S3

Weird, only get one page of articles at https://matthewkmayer.github.io/blag/public/ .

https://matthewkmayer.github.io/blag/public/post/rusoto-codegen/ has no link to it any more.

See how we can get syntax highlighting with the code snippets.

There's always the embedded gist option.

Post up my findings on making this work.