Keybase proof
I hereby claim:
- I am kirushik on github.
- I am kirushik (https://keybase.io/kirushik) on keybase.
- I have a public key whose fingerprint is 655D F5CB FECD 6718 CFC8 2949 FBF0 C4CB 6A37 5D79
To claim this, I am signing this object:
New GPG key for security@parity.io email | |
At Parity we’re always looking for ways to improve our security. As phishing exploits continue increasing in sophistication, we have been thinking about how to ensure the trustability of our critical security messages. | |
We receive critical security messages through security@parity.io. In order to ensure that the recipient can trust that we are the only receiver of these emails, they encrypt their message with GPG keys, which enable signing and encrypting emails. | |
GPG keys have a two-year lifespan. While it’s possible to extend the lifetime of the keys, when facing the end of our security@parity.io key lifespan, out of an abundance of caution, we decided to issue a new key instead of extending the existing key. | |
Up until Sunday July 21, 2019, our security@parity.io GPG key has this fingerprint: | |
DAE5 1560 28CF 37A0 7C69 3883 5D0F 0301 8D07 DE73 |
#!/bin/bash | |
gnote --search="`xsel`" |
I hereby claim:
To claim this, I am signing this object:
#!/usr/bin/env ruby | |
require 'rubygems' | |
require 'mechanize' | |
require 'uri' | |
a = Mechanize.new | |
root = URI.parse('https://en.wikipedia.org/wiki/List_of_Star_Trek:_The_Next_Generation_episodes') |
I hereby claim:
To claim this, I am signing this object:
Автор — kirill@pimenov.cc
Лицензия — CC BY-SA 4.0, https://creativecommons.org/licenses/by-sa/4.0/deed.ru
Во-первых, гит — это тоже такой себе блокчейн.
Собственно блок-чейн, цепочка блоков — это структура, где каждое текущее положение определяется хешем, который вычисляется из прошлого по функции new_block = hash(old_block+metadata+data)
Где data
— это собственно полезная нагрузка, скажем информация из каких файлов в какие какие строки переместились, или с каких кошельков на какие деньги переводятся.
We at SCC Team (and at SUSE in general) are providing more and more APIs with the wonderful HTTP REST approach. APIs evolve over time, often unexpectedly — so it makes sense to get into some API versioning best practices right from the day 0. I was asked to join Crowbar guys' discussion to share my SCC experience with versioning APIs. This article is an attempt to formalize our solution and prepare it for a wider audience.
So, imagine you have different API consumers out of your area of control. Some of them definitely will lag behind the latest release.
Today every self-respecting developer thinks of microservices and containers. This approach significantly simplifies deployments and maintenance efforts, while shortening the development-to-production cycle length.
But there are some quite weakly addressed pain points on that route: we can reliably deploy a product as a swarm of weakly-linked containers, but we're lacking most of the usual tools to get insights of what's happening inside those containers|services, and how to debug and troubleshoot our production issues.
As a team in the middle of such transition, we at SCC have hit most of those issues:
#!/usr/bin/env ruby | |
require 'find' | |
ACCESS_DENIED = ["$Recycle.Bin", "Documents and Settings", "Program Files", "Program Files (x86)", "ProgramData", ".", ".."] | |
def search(name, dirname = ".") | |
Find.find(dirname).find do |path| | |
! ACCESS_DENIED.include?(File.basename(path)) && | |
! File.directory?(path) && | |
File.basename(path) == name |
call plug#begin() | |
Plug 'junegunn/seoul256.vim' | |
Plug 'tpope/vim-sensible' | |
"Plug 'benekastah/neomake' | |
Plug 'Shougo/deoplete.nvim' | |
Plug 'junegunn/fzf', { 'dir': '~/.fzf', 'do': './install --all' } | |
Plug 'leafgarland/typescript-vim', { 'for': 'typescript' } |