Harry Dobrev hkdobrev

Auto-Deploying via Travis CI

Because Travis CI can automatically execute scripts after successfully (or unsuccessfully!) executing tests, it is an obvious choice for a deployment tool. In order to deploy to a Git repository on a remote server, the process generally is as follows:

Set up SSH keys
Add the server's copy of the repository as a Git remote
Push to the remote
SSH into the server and execute any installation/compilation/miscellaneous commands

Before even touching `.travis.yml`...

Users

Exporting your 2FA tokens from Authy to transfer them into another 2FA application

IMPORTANT - Update regarding deprecation of Authy desktop apps

Past August 2024, Authy stopped supported the desktop version of their apps:
See Authy is shutting down its desktop app | The 2FA app Authy will only be available on Android and iOS starting in August for details.

And indeed, after a while, Authy changed something in their backend which now prevents the old desktop app from logging in. If you are already logged in, then you are in luck, and you can follow the instructions below to export your tokens.

If you are not logged in anymore, but can find a backup of the necessary files, then restore those files, and re-install Authy 2.2.3 following the instructions below, and it should work as expected.

If you want to use travis_retry from within your own shell script files then you first have to make the travis_retry shell function available by sourcing the travis_retry.sh file, otherwise you just get a "command not found" error. See example.sh for a full example.

Note that the original function as found in the travis-ci/travis-build repository was slightly modified to allow it to be used in a shell context where set -e is enabled.

For reference, a tweet by Travis CI saying that you should copy the travis_retry code as I've done here: https://twitter.com/plexus/status/499194992632811520

Hyperlinks (a.k.a. HTML-like anchors) in terminal emulators

[ Update 2025-03-24: Commenting is disabled permanently. Previous comments are archived at web.archive.org. ]

Most of the terminal emulators auto-detect when a URL appears onscreen and allow to conveniently open them (e.g. via Ctrl+click or Cmd+click, or the right click menu).

It was, however, not possible until now for arbitrary text to point to URLs, just as on webpages.

Recently CSS has got a lot of negativity. But I would like to defend it and show, that with good naming convention CSS works pretty well.

My 3 developers team has just developed React.js application with 7668 lines of CSS (and just 2 !important). During one year of development we had 0 issues with CSS. No refactoring typos, no style leaks, no performance problems, possibly, it is the most stable part of our application.

Here are main principles we use to write CSS for modern (IE11+) browsers:

SUIT CSS naming conventions + SUIT CSS design principles;
PostCSS + CSSNext. Future CSS syntax like variables, nesting, and autoprefixer are good enough;
Flexbox is awesome. No need for grid framework;
Normalize.css, base styles and variables are solid foundation for all components;

What forces layout / reflow

All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.

Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.

Element APIs

Getting box metrics

elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent

	Replace this line with imperative summary

	An awesome description of WHY you did this work, not HOW/WHAT it does.
	The diff attached to commit should describe implementation (HOW)
	well-enough.

	# [TICKET-12]

	#------------------------------------------------^---------------------^
	# 50^ 72^

	# Copyright 1999-2011 Gentoo Foundation
	# Distributed under the terms of the GNU General Public License v2
	#
	# /etc/screenrc
	#
	# This is the system wide screenrc.
	#
	# You can use this file to change the default behavior of screen system wide
	# or copy it to ~/.screenrc and use it as a starting point for your own
	# settings.

	# This task will notify Sentry via their API[1] that you have deployed
	# a new release. It uses the release timestamp as the `version`
	# (like 20151113182847) and the git ref as the optional `ref` value.
	#
	# This task requires several environment variables be set (or just
	# hardcode the values in here if you like living on the edge):
	#
	# ENV['SENTRY_API_ENDPOINT'] : API endpoint, https://app.getsentry.com
	# ENV['SENTRY_ORG'] : the organization for this app
	# ENV['SENTRY_PROJECT'] : the project for this app

	<?php

	namespace Acme\Serializer\Normalizer;

	use Doctrine\Common\Collections\ArrayCollection;
	use Doctrine\Common\Collections\Collection;
	use Symfony\Component\Serializer\Normalizer\DenormalizerInterface;
	use Symfony\Component\Serializer\Normalizer\NormalizerInterface;
	use Symfony\Component\Serializer\Normalizer\SerializerAwareNormalizer;