Skip to content

Instantly share code, notes, and snippets.

View pvillega's full-sized avatar
😶‍🌫️
Too much!

Pere Villega pvillega

😶‍🌫️
Too much!
View GitHub Profile
@pvillega
pvillega / 20auto-upgrades
Last active June 13, 2022 12:21 — forked from anatolebeuzon/20auto-upgrades
Unattended-upgrades config for Raspberry Pi running Raspbian - /etc/apt/apt.conf.d
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "3";
APT::Periodic::Verbose "1";
APT::Periodic::Unattended-Upgrade "1";
@pvillega
pvillega / do_cloud-config.init.yaml
Created August 6, 2020 20:07 — forked from c0psrul3/do_cloud-config.init.yaml
Digital Ocean cloud-init / cloud-config / droplet metadata usage
#
#DO droplet metadata intro + for DO-API
# [https://www.digitalocean.com/community/tutorials/an-introduction-to-droplet-metadata#how-to-retrieve-droplet-metadata#digitalocean-api]
#
#intro to cloud-config scripting (source of following examples)
# [https://www.digitalocean.com/community/tutorials/an-introduction-to-cloud-config-scripting]
#
#howto
# [https://www.digitalocean.com/community/tutorials/how-to-use-cloud-config-for-your-initial-server-setup]
#
@pvillega
pvillega / install-teamcity.md
Created August 4, 2020 20:21 — forked from simoneb/install-teamcity.md
Install TeamCity on Ubuntu with Nginx

"Specifying distributed systems with TLA+"

Elevator pitch:

Learn how to use TLA+ to study, design, and specify your algorithms. This workshop is designed to teach you about TLA+ from the ground up. We will start with simple distributed algorithms and slowly move toward more complex ones. Knowledge you gain can be immediatly applied at work the day after the workshop

Description:

TLA+ is a formal specification language developed by Leslie Lamport, designed to specify, model, document, and verify concurrent systems. It empowers your ability to clearly specify your design choices by using a formal specification, but even more importantly it can also formally verify that your design choice is correct — meaning that it is both safe (does not break any rules) and live (over time it converges toward the result).

@pvillega
pvillega / readme.md
Created April 16, 2019 19:20 — forked from laughedelic/sbt-dependency-management-guide.md
Explicit dependency management in sbt

Some of these practices might be based on wrong assumptions and I'm not aware of it, so I would appreciate any feedback.

  1. avoiding some dependency conflicts:

    • add sbt-explicit-dependencies to the project/plugins.sbt
    • run undeclaredCompileDependencies and add any missing explicit dependencies to libraryDependencies of each sub-project
    • (optionally) run unusedCompileDependencies and remove some obvious unused libraries. This has false positives, so ; reload; Test/compile after each change and ultimately run all tests to see that it didn't break anything
    • (optionally) add undeclaredCompileDependenciesTest to the CI pipeline, so that it will fail if you have some undeclared dependencies
  2. keeping dependencies up to date and resolving conflicts:

  • install sbt-updates globally in your ~/.sbt/{0.13,1.0}/plugins/plugins.sbt
[
{name: 'Afghanistan', code: 'AF'},
{name: 'Åland Islands', code: 'AX'},
{name: 'Albania', code: 'AL'},
{name: 'Algeria', code: 'DZ'},
{name: 'American Samoa', code: 'AS'},
{name: 'AndorrA', code: 'AD'},
{name: 'Angola', code: 'AO'},
{name: 'Anguilla', code: 'AI'},
{name: 'Antarctica', code: 'AQ'},