Timesled deploy is ready to go

Timesled deploy is ready to go

Today I don't feel like coding a lot, so I'm crossing one of the easy issues that I had on my list. I prepared a simple nextjs scaffold and deployed it to


Build your own work feed

Build your own work feed

Why would you want a side project if you can have two :trollface:.

I'm starting to work with Adrián on transforming the concept of this work feed into a real product. I'll be writing a lot more about it while we build it.

We want to have something ready to ship very fast, so we are using Max Stoiber and Brian Lovin's product boilerplate as our initial foundation. I'm thoroughly impressed by how fast we were able to go from nothing to start working on our data model.


Capture, compare, minify, store

Capture, compare, minify, store

Today was cleanup time. I broke a gigantic index.js into manageable pieces and tried to tidy some of the mess that I did while I was building the concept.

I made some progress with the storage, and I have a few ideas for abstracting different providers. I'd love to start capturing three times a week to have data for feeding the frontend of the project.


Stuck!

Stuck!

Got stuck in a potentially stupid thing, and wrote a bunch of spaghetti code that I'll need to throw away tomorrow.

On the bright side, I think that I understand a lot better how to deal with AzStorage. 🤷🏼‍♂️


Capture and minify

Capture and minify

The action now iterates over a few devices and a list of URLs. It is slow, but that was expected.

I'm worried about the size of each run, to the point where I'm considering implementing the storage layer straight away. I also implemented minification, but I wonder if it is going to mess with pixelmatch.


Diffs

Diffs

I played today with pixelmatch. I want to detect differences between screens from day to day.

One of the challenges of using pixelmatch is the difference in sizes when you are capturing full screen websites. If the images don't match in size, the script raises an error. I have been writing some code to overcome that problem.


Building a time machine

Building a time machine

I'm starting a little project to automate the screenshoting of a bunch of endpoints. I want to be able to compare them and go back in time.

A long time ago, I imagined a simpler version of this project, and even registered uihop.com with the intention of builidng a decent service behind it. Years later, during my time at Yammer, Brendan McKeon impressed the whole company with the many uses of his "time machine". I was impressed and inspired by his work, and bummed because that piece of technology wasn't available for more designers.

For now, I started the project creating a very simple action that launches puppeteer inside a docker container and parses a config file with resolutions and a list of URLs.





PR-it!

PR-it!

I finished the action that will send me a daily PR with the scaffold of a post. I learned a lot from dissecting Jason's code, and clarified some concepts reading this super thorough article from Jeff Rafter.


Automating the hell out of this

Automating the hell out of this

I want GitHub to have a pull request ready every day when I arrive home. That should help me to overcome the repetitive part of keeping this project alive 🎉.

Will post about it once it is ready.


Actions

Actions

If I want to keep this feed alive with minimum infrastructural effort, I want to automate the hell out of it. I'm learning a lot from the actions that Jason Etco has published.



LA Convertibles

LA Convertibles
  • OLYMPUS IMAGING CORP. E-M5
  • ƒ/5
  • 1/800s
  • ISO 200


Joshua Tree

Joshua Tree
  • OLYMPUS IMAGING CORP. E-M5
  • ƒ/1.7
  • 1/160s
  • ISO 200

Bisons of Utah

Bisons of Utah
  • Apple iPhone 6
  • ƒ/2.2
  • 1/9901s
  • ISO 32
  • 37.246412 112.803528

Horseshoe Bend

Horseshoe Bend
  • Apple iPhone 6
  • ƒ/2.2
  • 1/2639s
  • ISO 32
  • 36.878942 111.510812

Dumplings

Dumplings
  • Apple iPhone 6
  • ƒ/2.2
  • 1/30s
  • ISO 125
  • 37.326022 -121.944108

← PreviousNext →