суббота, 20 января 2018 г.
Расчёт сопел современных ракетных двигателей
Введение
Сопло ракетного двигателя- техническое приспособление, которое служит для ускорения газового потока, проходящего по нему до скоростей, превышающих скорость звука. Основные виды профилей сопел приведены на рисунке:
По причине высокой эффективности ускорения газового потока, нашли практическое применение сопла Лаваля. Сопло представляет собой канал, суженный в середине. В простейшем случае такое сопло может состоять из пары усечённых конусов, сопряжённых узкими концами:
В ракетном двигателе сопло Лаваля впервые было использовано генералом М. М. Поморцевым в 1915 году. В ноябре 1915 года в Аэродинамический институт обратился генерал М. М. Поморцев с проектом боевой пневматической ракеты.
Ракета Поморцева приводилась в движение сжатым воздухом, что существенно ограничивало ее дальность, но зато делало ее бесшумной. Ракета предназначалась для стрельбы из окопов по вражеским позициям. Боеголовка оснащалась тротилом.
В ракете Поморцева было применено два интересных конструктивных решения: в двигателе имелось сопло Лаваля, а с корпусом был связан кольцевой стабилизатор. Подобные конструкции используются и в настоящее время, но уже с твёрдотопливным двигателем и системой автоматического наведения:
Однако проблемы остались старые, но уже в современном исполнении: ограниченная дальность до 3 км., наведение и удержание цели в условиях хорошей видимости, что для настоящего боя не реально, не защищённость от электромагнитных заградительных помех и, наконец, но не в последнюю очередь, высокая стоимость.
Теоретические основы
Эффективные сопла современных ракетных двигателей профилируются на основании специальных газодинамических расчётов. Основное уравнение, связывающее градиент площади сечения, градиент скорости и число Маха, следующее:
где: S – площадь сечения сопла; v – скорость газа; M – число Маха (отношение скорости газа в какой-либо точке потока к скорости звука в этой же точке).
Анализируя это соотношение, получаем, что в сопле Лаваля могут осуществляться следующие режимы течения:
1) M <1 – поток на входе дозвуковой: [1]
а) 
<0, тогда 
>0 (из уравнения). Дозвуковой поток в сужающемся канале ускоряется.
б) >0, тогда <0. Дозвуковой поток в расширяющемся канале тормозится.
2) M>1 – поток на входе сверхзвуковой:
а) <0, тогда <0. Сверхзвуковой поток в сужающемся канале тормозится.
б) >0, тогда >0. Сверхзвуковой поток в расширяющемся канале ускоряется.
3) = 0 – самое узкое место сопла, минимальное сечение.
Тогда возможно либо М = 1 (поток переходит через скорость звука), либо = 0 (экстремум скорости).
Какой из режимов реализуется на практике, зависит от перепада давлений между входом в сопло и окружающей средой.
Если давление, достигаемое в критическом сечении, превышает наружное давление, то поток на выходе из сопла будет сверхзвуковым. В противном случае он остается дозвуковым. [2]
— условие сверхзвукового истечения.
где: p* – давление торможения (давление в камере); pкр – давление в критическом сечении сопла; pнар – давление в окружающей среде; k – показатель адиабаты.
Если известны параметры в камере сгорания, то параметры в любом сечении сопла можно узнать по следующим соотношениям:
давление:
или 
;
температуру:
или 
;
плотность:
или 
;
скорость:
или 
.
В этих формулах – λ – приведенная скорость, отношение скорости газа в данном сечении сопла к скорости звука в критическом сечении, R – удельная газовая постоянная. Индексом «*» обозначены параметры торможения (в данном случае – параметры в камере сгорания).
Постановка задачи
1. Рассчитать параметры течения потока газов в сопле Лаваля: для этого профиль сопла Лаваля разбивается на 150 контрольных точек –
. Разбиение осуществляем таким образом, чтобы минимальное сечение располагалось в точке 
. Определяются значения газодинамических функций давления, плотности и температуры в каждом сечении.
2. Расчёты выполнить средствами высокоуровневого свободно распространяемого языка программирования Python по следующей расчётной схеме и исходным данным:
Рисунок 1-Профиль сопла Лаваля
Таблица 1-Исходные данные
Приведенные исходные данные носят демонстрационный характер.
Расчёт сопла Лаваля средствами Python
#!/usr/bin/env python
#coding=utf8
import matplotlib.pyplot as plt
import matplotlib as mpl
mpl.rcParams['font.family'] = 'fantasy'
mpl.rcParams['font.fantasy'] = 'Comic Sans MS, Arial'
import numpy as np
from math import *
alfa=21.0#Угол сужения
beta=11.5#Угол расширения
rkr=1.1#Радиус критического сечения
R0=2*rkr
r1=0.5*rkr# Радиус округления сужающейся части сопла
r2=0.8*rkr# Радиус округления расширяющейся части сопла
ye=rkr+r2
L=1.2*R0#Длина прямого участка сопла Лаваля
x0=0
y0=R0
xa=L
ya=y0
xc1=xa
yc1=ya-r1
xc=xa+r1*cos(radians(90-alfa))
yc=yc1+r1*sin(radians(90-alfa))
yd=ye-r2*sin(radians(90-alfa))
xd=xc+(yc-yd)/tan(radians(alfa))
xc2=xd+r2*sin(radians(alfa))
xe=xc2
xf=xe+r2*cos(radians(90-beta))
yf=ye-r2*sin(radians(90-beta))
def R(x):
if x0<=x<=xa:
return ya*1e-4
if xa<=x<=xc:
return (yc1+sqrt(r1**2-(x-xc1)**2))*1e-4
if xc<=x<=xd:
return (-tan(radians(alfa))*(x-xc)+yc)*1e-4
if xd<=x<=xf:
return (ye-sqrt(r2**2-(x-xe)**2))*1e-4
if xf<=x:
return (yf+tan(radians(beta))*(x-xf))*1e-4
y=[R(x+xe) for x in np.arange(-5,5,0.01)]
x=np.arange(-5,5,0.01)
plt.figure()
plt.title('Профиль сопла ')
plt.axis([-5.0, 5.0, 0.0, 3.0*10**-4])
plt.plot(x,y,'r')
plt.grid(True)
plt.figure()
plt.title('Изменение площади проходного \n сечения сопла вдоль его продольной оси ')
yy=[pi*R(x+xe)**2 for x in np.arange(-5,5,0.01)]
plt.plot(x,yy,'r')
plt.grid(True)
plt.show()
Для продолжения решения задачи на Python, нужно связать λ – приведенную скорость газа с координатой x вдоль продольной оси. Для этого я воспользовался функцией fsolve из библиотеки SciPy со следующей инструкцией:
fsolve(<функция>,<стартовая точка>,xtol=1.5 · 10^8)
Привожу фрагмент программы для управления решателем с одной стартовой точкой:
def lamda(z):
m=round(Q(z),2)
if z>= 0:
x=fsolve(lambda x:x*( (1-(1/6)*x**2)**2.5)/((1-(1/6))**2.5)-m,1.5)
return x[0]
if z<0:
x=fsolve(lambda x:x*( (1-(1/6)*x**2)**2.5)/((1-(1/6))**2.5)-m,0.5)
return x[0]
Это единственно возможное на Python решение сложного алгебраического уравнения со степенной функцией от показателя адиабаты k. Например, даже для упрощённого уравнения с использованием библиотеки SymPy, получим недопустимое время расчёта только одной точки:
from sympy import *
import time
x = symbols('x',real=True)
start = time.time()
start = time.time()
d=solve( 1.5774409656148784068*x *(1.0-0.16666666666666666667*x**2)**2.5-0.25,x)
stop = time.time()
print ("Время работы решателя:",round(stop-start,3))
print(round(d[0],3))
print(round(d[1],3))
Время работы решателя: 195.675
0.16
1.95
#!/usr/bin/env python
#coding=utf8
import matplotlib.pyplot as plt
import matplotlib as mpl
mpl.rcParams['font.family'] = 'fantasy'
mpl.rcParams['font.fantasy'] = 'Comic Sans MS, Arial'
import numpy as np
from math import *
from scipy.optimize import *
import time
start = time.time()
alfa=21.0#Угол сужения
beta=11.5#Угол расширения
rkr=1.1#Радиус критического сечения
R0=2*rkr
r1=0.5*rkr#Радиус округления сужающейся части сопла
r2=0.8*rkr#Радиус округления расширяющейся части сопла
ye=rkr+r2
L=1.2*R0#Длина прямого участка сопла Лаваля
x0=0
y0=R0
xa=L
ya=y0
xc1=xa
yc1=ya-r1
xc=xa+r1*cos(radians(90-alfa))
yc=yc1+r1*sin(radians(90-alfa))
yd=ye-r2*sin(radians(90-alfa))
xd=xc+(yc-yd)/tan(radians(alfa))
xc2=xd+r2*sin(radians(alfa))
xe=xc2
xf=xe+r2*cos(radians(90-beta))
yf=ye-r2*sin(radians(90-beta))
def R(x):
if x0<=x<=xa:
return ya*1e-4
if xa<=x<=xc:
return (yc1+sqrt(r1**2-(x-xc1)**2))*1e-4
if xc<=x<=xd:
return (-tan(radians(alfa))*(x-xc)+yc)*1e-4
if xd<=x<=xf:
return (ye-sqrt(r2**2-(x-xe)**2))*1e-4
if xf<=x:
return (yf+tan(radians(beta))*(x-xf))*1e-4
def S(x):
return pi*R(x+xe)**2
xg=2*xe
n=150
RG=287 #Газовая постоянная
Tt=611 #Температура торможения
k=1.4
def tau(x):
return 1-(1/6)*x**2
def eps(x):
return (1-(1/6)*x**2)**2.5
def pip(x):
return 1-(1/6)*x**2
def Q(z):
return S(0)/S(z)
x=[x0-xe+(i/n)*(xg-x0) for i in np.arange(0,n,1)]
def lamda(z):
m=round(Q(z),2)
if z>= 0:
x=fsolve(lambda x:x*( (1-(1/6)*x**2)**2.5)/((1-(1/6))**2.5)-m,1.5)
return x[0]
if z<0:
x=fsolve(lambda x:x*( (1-(1/6)*x**2)**2.5)/((1-(1/6))**2.5)-m,0.5)
return x[0]
plt.title('Газодинамическая функция приведенной скорости')
y=[lamda(z) for z in x]
stop = time.time()
print ("Время работы программы:",round(stop-start,3))
plt.ylabel('λ(xi)-отношение скорости газа к скорости звука' )
plt.plot(0, 1, color='b', linestyle=' ', marker='o', label='Сужение сопла')
plt.xlabel('xi -координата вдоль оси сопла')
plt.plot(x,y,'r')
plt.legend(loc='best')
plt.grid(True)
plt.show()
Время работы программы: 0.222
Вывод:
Полученная эпюра распределения скоростей газового потока полностью соответствует изложенной выше теории. При этом, по предложенному алгоритму и библиотеке, время расчёта в 150 точках в 1000 раз меньше, чем для одной точки с использованием solve sympy.
#!/usr/bin/env python
#coding=utf8
import matplotlib.pyplot as plt
import matplotlib as mpl
mpl.rcParams['font.family'] = 'fantasy'
mpl.rcParams['font.fantasy'] = 'Comic Sans MS, Arial'
import numpy as np
from math import *
from scipy.optimize import *
import time
start = time.time()
alfa=21.0#Угол сужения
beta=11.5#Угол расширения
rkr=1.1#Радиус критического сечения
R0=2*rkr
r1=0.5*rkr#Радиус округления сужающейся части сопла
r2=0.8*rkr#Радиус округления расширяющейся части сопла
ye=rkr+r2
L=1.2*R0#Длина прямого участка сопла Лаваля
x0=0
y0=R0
xa=L
ya=y0
xc1=xa
yc1=ya-r1
xc=xa+r1*cos(radians(90-alfa))
yc=yc1+r1*sin(radians(90-alfa))
yd=ye-r2*sin(radians(90-alfa))
xd=xc+(yc-yd)/tan(radians(alfa))
xc2=xd+r2*sin(radians(alfa))
xe=xc2
xf=xe+r2*cos(radians(90-beta))
yf=ye-r2*sin(radians(90-beta))
def R(x):
if x0<=x<=xa:
return ya*1e-4
if xa<=x<=xc:
return (yc1+sqrt(r1**2-(x-xc1)**2))*1e-4
if xc<=x<=xd:
return (-tan(radians(alfa))*(x-xc)+yc)*1e-4
if xd<=x<=xf:
return (ye-sqrt(r2**2-(x-xe)**2))*1e-4
if xf<=x:
return (yf+tan(radians(beta))*(x-xf))*1e-4
def S(x):
return pi*R(x+xe)**2
xg=2*xe
n=150
RG=287 #Газовая постоянная
Tt=611 #Температура торможения
k=1.4
def tau(x):
return 1-(1/6)*x**2
def eps(x):
return (1-(1/6)*x**2)**2.5
def pip(x):
return 1-(1/6)*x**2
def Q(z):
return S(0)/S(z)
x=[x0-xe+(i/n)*(xg-x0) for i in np.arange(0,n,1)]
def lamda(z):
m=round(Q(z),2)
if z>= 0:
x=fsolve(lambda x:x*( (1-(1/6)*x**2)**2.5)/((1-(1/6))**2.5)-m,1.5)
return x[0]
if z<0:
x=fsolve(lambda x:x*( (1-(1/6)*x**2)**2.5)/((1-(1/6))**2.5)-m,0.5)
return x[0]
plt.title('Газодинамическая функция температуры')
t0=293
y=[ t0*tau(lamda(z)) for z in x]
stop = time.time()
print (" Время работы программы:",round(stop-start,3))
plt.ylabel('T(xi)-температура газового потока град. С' )
plt.xlabel('xi -координата вдоль оси сопла')
plt.plot(x,y,'r')
plt.grid(True)
plt.show()
Время работы программы: 0.203
Вывод
Температура на выходе из сопла уменьшается по приведенному в листинге уравнению газодинамики. Время выполнения программы приемлемое -0.203.
Испытательная установка:
#!/usr/bin/env python
#coding=utf8
import matplotlib.pyplot as plt
import matplotlib as mpl
mpl.rcParams['font.family'] = 'fantasy'
mpl.rcParams['font.fantasy'] = 'Comic Sans MS, Arial'
import numpy as np
from math import *
from scipy.optimize import *
import time
start = time.time()
alfa=21.0#Угол сужения
beta=11.5#Угол расширения
rkr=1.1#Радиус критического сечения
R0=2*rkr
r1=0.5*rkr#Радиус округления сужающейся части сопла
r2=0.8*rkr#Радиус округления расширяющейся части сопла
ye=rkr+r2
L=1.2*R0#Длина прямого участка сопла Лаваля
x0=0
y0=R0
xa=L
ya=y0
xc1=xa
yc1=ya-r1
xc=xa+r1*cos(radians(90-alfa))
yc=yc1+r1*sin(radians(90-alfa))
yd=ye-r2*sin(radians(90-alfa))
xd=xc+(yc-yd)/tan(radians(alfa))
xc2=xd+r2*sin(radians(alfa))
xe=xc2
xf=xe+r2*cos(radians(90-beta))
yf=ye-r2*sin(radians(90-beta))
def R(x):
if x0<=x<=xa:
return ya*1e-4
if xa<=x<=xc:
return (yc1+sqrt(r1**2-(x-xc1)**2))*1e-4
if xc<=x<=xd:
return (-tan(radians(alfa))*(x-xc)+yc)*1e-4
if xd<=x<=xf:
return (ye-sqrt(r2**2-(x-xe)**2))*1e-4
if xf<=x:
return (yf+tan(radians(beta))*(x-xf))*1e-4
def S(x):
return pi*R(x+xe)**2
xg=2*xe
n=150
RG=287 #Газовая постоянная
Tt=611 #Температура торможения
k=1.4
def tau(x):
return 1-(1/6)*x**2
def eps(x):
return (1-(1/6)*x**2)**2.5
def pip(x):
return 1-(1/6)*x**2
def Q(z):
return S(0)/S(z)
x=[x0-xe+(i/n)*(xg-x0) for i in np.arange(0,n,1)]
def lamda(z):
m=round(Q(z),2)
if z>= 0:
x=fsolve(lambda x:x*( (1-(1/6)*x**2)**2.5)/((1-(1/6))**2.5)-m,1.5)
return x[0]
if z<0:
x=fsolve(lambda x:x*( (1-(1/6)*x**2)**2.5)/((1-(1/6))**2.5)-m,0.5)
return x[0]
plt.title('Газодинамическая функция давления')
p0=3.6
y=[ 3.6*pip(lamda(z)) for z in x]
stop = time.time()
print ("Время работы программы:",round(stop-start,3))
plt.ylabel('P(xi)-давление газового потока в МПа' )
plt.xlabel('xi -координата вдоль оси сопла')
plt.plot(x,y,'r')
plt.grid(True)
plt.show()
Время работы программы: 0.203
Вывод
Давление на выходе из сопла уменьшается по приведенному в листинге уравнению газодинамики. Время выполнения программы приемлемое -0.203.
Возникновение силы тяги от действия давления газа схематично показано на рисунке:
#!/usr/bin/env python
#coding=utf8
import matplotlib.pyplot as plt
import matplotlib as mpl
mpl.rcParams['font.family'] = 'fantasy'
mpl.rcParams['font.fantasy'] = 'Comic Sans MS, Arial'
import numpy as np
from math import *
from scipy.optimize import *
import time
start = time.time()
alfa=21.0#Угол сужения
beta=11.5#Угол расширения
rkr=1.1#Радиус критического сечения
R0=2*rkr
r1=0.5*rkr#Радиус округления сужающейся части сопла
r2=0.8*rkr#Радиус округления расширяющейся части сопла
ye=rkr+r2
L=1.2*R0#Длина прямого участка сопла Лаваля
x0=0
y0=R0
xa=L
ya=y0
xc1=xa
yc1=ya-r1
xc=xa+r1*cos(radians(90-alfa))
yc=yc1+r1*sin(radians(90-alfa))
yd=ye-r2*sin(radians(90-alfa))
xd=xc+(yc-yd)/tan(radians(alfa))
xc2=xd+r2*sin(radians(alfa))
xe=xc2
xf=xe+r2*cos(radians(90-beta))
yf=ye-r2*sin(radians(90-beta))
def R(x):
if x0<=x<=xa:
return ya*1e-4
if xa<=x<=xc:
return (yc1+sqrt(r1**2-(x-xc1)**2))*1e-4
if xc<=x<=xd:
return (-tan(radians(alfa))*(x-xc)+yc)*1e-4
if xd<=x<=xf:
return (ye-sqrt(r2**2-(x-xe)**2))*1e-4
if xf<=x:
return (yf+tan(radians(beta))*(x-xf))*1e-4
def S(x):
return pi*R(x+xe)**2
xg=2*xe
n=150
RG=287 #Газовая постоянная
Tt=611 #Температура торможения
k=1.4
def tau(x):
return 1-(1/6)*x**2
def eps(x):
return (1-(1/6)*x**2)**2.5
def pip(x):
return 1-(1/6)*x**2
def Q(z):
return S(0)/S(z)
x=[x0-xe+(i/n)*(xg-x0) for i in np.arange(0,n,1)]
def lamda(z):
m=round(Q(z),2)
if z>= 0:
x=fsolve(lambda x:x*( (1-(1/6)*x**2)**2.5)/((1-(1/6))**2.5)-m,1.5)
return x[0]
if z<0:
x=fsolve(lambda x:x*( (1-(1/6)*x**2)**2.5)/((1-(1/6))**2.5)-m,0.5)
return x[0]
plt.title('Газодинамическая функция относительной плотности газа')
y=[ eps(lamda(z)) for z in x]
stop = time.time()
print ("Время работы программы:",round(stop-start,3))
plt.ylabel('Относительная плотность' )
plt.xlabel('xi -координата вдоль оси сопла')
plt.plot(x,y,'r')
plt.grid(True)
plt.show()
Время работы программы: 0.203
Вывод
Плотность газа на выходе из сопла уменьшается по приведенному в листинге уравнению газодинамики. Время выполнения программы приемлемое.
Выводы
1. Разработан метод решения средствами Python вещественных корней нелинейных степенных уравнений с дробными показателями степени используемых для описания газодинамических процессов. Метод основан на применении решателя fsolve из модуля scipy. optimize.
2. С помощью разработанного метода, решена демонстрационная задача расчёта сопла современных ракетных двигателей с определением следующих газодинамических функций: скорости; температуры; давления; плотности реактивных газов.
Ссылки
1. А. А. Дорофеев Основы теории тепловых ракетных двигателей (Общая теория ракетных двигателей) МГТУ им. Н. Э. Баумана Москва 1999 г.
2. Ландау Л. Д., Лифшиц Е. М. Глава X. Одномерное движение сжимаемого газа. § 97. Истечение газа через сопло // Теоретическая физика. — Т. 6. Гидродинамика.
Американские биржи обвиняют в незаконном предоставлении преимуществ высокочастотным трейдерам
Изображение: Spiros Vathis | CC BY-ND 2.0
В 2014 году была опубликована книга Майкла Льюиса “Flash Boys” — в ней рассказывалось об устройстве индустрии высокочастотной биржевой торговли и описывались не всегда полностью честные методы, используемые трейдерами. Книга стала бестселлером и вызвала широкий общественный резонанс.
Более того, по ее следам деятельностью высокочастотных торговцев заинтересовались власти, к некоторым HFT-фирмам были поданы иски. Никаких видимых результатов этой активности в тот период не последовало, однако как стало известно изданию The Hill, разбирательства продолжаются до сих пор.
Претензии 2014 года
Регуляторы и юристы, после выхода ‘Flash boys’, начали проверять биржи на предоставление преимуществ HTF-торговцам. Согласно обвинениям, биржи создавали условия, при которых такие трейдеры получали торговые данные раньше других, что позволяло тем использовать тактику фронтраннинга для манипулирования ценами. На долю HFT в настоящий момент приходится большая часть объема торгов на американских биржах, поэтому торговые площадки заинтересованы в привлечении таких игроков.
Помимо поданных еще в 2014 году судебных исков, регуляторы предприняли и ряд действий, направленных на усиление контроля за HFT. Так Комиссия по ценным бумагам и биржам США (SEC) разработала сайт департамента по представлению данных и анализу структуры рынка. Позднее ведомство пригласило экспертов по торговле и создало Консультативный комитет по структуре рынка акций (EMSAC), который занимался исключительно вопросами высокочастотных трейдеров.
Что происходит сейчас
Федеральный апелляционный суд США 19 декабря вновь восстановил иск к нескольким биржам, включая NYSE, NASDAQ, BATS Exchange и Cboe. На данный момент представители бирж никак не отреагировали на обвинение, хотя ранее отрицали свою вину.
В иске утверждается, что биржи, заведомо зная о последствиях, предоставили HTF-фирмам более быстрый доступ к торговым данным, в ущерб другим инвесторам. В свою очередь, биржи утверждают, что размещение серверов трейдеров в том же дата-центре, что и биржевая торговая система, а также прямое подключение соответствуют нормам SEC.
Также они утверждают, что HFT-фирмы вкладывают значительные средства в развитие финансовых технологий, что дает им возможность конкурировать за объемы торгов, улучшать ликвидность и повышать эффективность рынка для всех инвесторов.
Между тем, EMSAC изучает различные аспекты деятельность HFT уже несколько лет, но пока не представил четкого обоснования обвинений во фронтраннинге.
Представители организации Modern Markets Initiative, которые поддерживают высокочастотных трейдеров, обращают внимание на то, что не было получено чётких объяснений по поводу исков к HFT-торговле, как и того, как схема фронтраннига, описанная в книге «Flash Boys», может работать в нынешней структуре рынка. Кроме того не было получено информации от других участников рынка, которые могут подтвердить, что предъявляемое трейдерам обвинение действительно имело место быть.
По мнению президента и главного исполнительного директора CFA Institute Пола Смита (Paul Smith), на эти вопросы нужно ответить раз и навсегда, так как тему конфиденциальности и доверия к рынку нельзя пускать на самотёк. Финансовые технологии крайне важны для биржевых торгов, но не когда они используются для манипуляции рынком.
Другие материалы по теме финансов и фондового рынка от ITI Capital:
Ну почему все стало так медленно?! Выбираем железо для разработки на Unity
«Короче, что лучше?»
Самые нетерпеливые сразу могут промотать в конец)
Когда тупит Unity?
Существует несколько операций, выполнение которых занимает много времени при работе с Unity. Обычно в таких случаях я иду чаевничать или играю с котом. Иногда даже удается пройти пару уроков в Duolingo.
- Обработка файлов проекта. Unity считает хэши всех файлов в проекте, создает мета-файлы и строит свою библиотеку (папка Library). Особенно долго Unity обрабатывает звуковые файлы. Библиотеку никто не хранит в системе контроля версий, поэтому если вы давно не синхронизировали проект, вас ждет пара минут ожидания. Кроме того, если изменить платформу, например с Android на iOS, этот процесс придется повторить.
- Запекание света (baking). Тут все зависит от сложности освещения. Я делаю мобильные игры, поэтому запекание практически не использую.
- Сборка проекта. Во многом зависит от выбранной платформы и самого проекта. WebGL может вообще собираться целую вечность (иногда реально состариться можно и еще борода отрастает). Я имею ввиду именно получение готовой игры, а не компиляцию исходного кода (которая происходит практически мгновенно).
Пару слов о моем 2500K
Intel Core i5 2500K вышел в 2011 году и относится к линейке Sandy Bridge (техпроцесс 32 нанометра). Частота 3,30 GHz (3,70 GHz с Turbo Boost), 4 ядра и 4 потока, кэш-память 6 Mb. Ничего особенного, если бы не адекватный ценник и приставка K. На хорошей mobo (у меня чипсет p67) гонится как черт (у всех Sandy Bridge под крышкой припой). У меня он 7 лет проработал на частоте 4.7 Ghz. На дворе 2018 год, а этот процессор до сих пор считается лучшим в бюджетном сегменте, на барахолке он стоит около 5000 рублей. В общем то, никаких особых неудобств при разработке я не испытываю, такого процессора вполне хватает. Почему не i7? Да потому что стоит он вдвое больше, а я денюжкой не сорю)
Видеокарта
Видеокарта непосредственно для разработки никакого значения не имеет. Она понадобится вам только для запуска и тестирования проектов. Если вы делаете игру для PC с «крутым графоном», стоит потратиться на хорошую видеокарту. Поскольку я делаю мобильные игры, у меня нет никакой нужды бежать в магазин за GTX 1080 (которую наверняка уже раскупили майнеры). Поэтому я решил оставить свою старушку GTX 460. Тем не менее, я проведу тест с двумя видеокартами.
Выбор процессора
С выходом Ryzen AMD вернулись на рынок процессоров. Поэтому выбор будет стоять между:
- Intel Core i5
- Intel Core i7
- Ryzen 5
- Ryzen 7
- Многоядерные серверные процессоры Xeon прошлых поколений (ибо стоят недорого)
Все, что ниже i5, а также старые процессоры AMD я рассматривать не буду (несмотря на все шутки про инди-разработчиков и дошираки).
Последний Core i5 — логичная замена моего i5 2500K. За эти 7 лет Intel, не имея никакой конкуренции и следуя своей концепции «Тик-так-так», прокачала свои процессоры в среднем на 50%. Поэтому даже если после покупки нового процессора Unity будет тупить в полтора раза меньше, я буду доволен.
Core i7 — камень для бояр, стоит вдвое больше i5. Нужен ли Hyper Threading за такие деньги? Согласно различным бенчмаркам, Hyper Threading обеспечивает прирост производительности до 30%.
Ryzen 5 и Ryzen 7 — новые 6-ядерные и 8-ядерные процессоры. Ядер больше, чем у Intel, но частоты меньше.
Серверные процессоры Xeon серий 16ХХ и 26ХХ имеют от 6 до 10 ядер (E5 2680 V2). Списанные с китайских серверов, они продаются на AliExpress по цене 100-150$, поэтому рассмотреть их стоит. Особенно, если вы ограничены в бюджете. Из минусов — придется купить китайскую материнку за 100$ и мощный кулер. Из плюсов — дешевая серверная DDR3 (регистровая).
После выхода Ryzen Intel оперативно скорректировал свой бизнес-план и выпустил шестиядерные процессоры. Если вам нужен процессор для игр, то выбирать нужно однозначно Intel. В большинстве игровых тестов даже 4-ядерные процессоры Intel, например i7 7700K, оказываются лучше Ryzen. Кроме того, гонятся до 5 Ghz даже на воздушном охлаждении.
Но у меня другой случай — я делаю игры, а не играю в них. Станут ли мои coffee break вдвое короче при использовании 8 ядер?
Увы, у меня нет возможности купить все эти процессоры, чтобы провести эксперимент. Но под рукой есть i5 2500K и серверный Xeon E5 1660 с шестью ядрами (будем считать его «аналогом» Ryzen 5, т.к. по бенчмаркам они очень близки). Вполне достаточно, чтобы определить, что же лучше для разработки на Unity.
Итак, будем тестировать:
- разогнанный i5 2500K (4С/4T) ~ 80$
- немного разогнанный (на хуанане особо не разгонишь) E5 1660 (6C/12T) ~ 130$
Замечу, что на E5 1660 удалось поставить максимальный множитель 42/42/42/42/0/0. Это значит, что при загрузке более 4-х ядер частота будет снижаться до базового значения 3600 Mhz (хотя на брендовых платах его гонят до 4800). i5 2500K же может работать на максимальной частоте 4700 Mhz при любой нагрузке.
Для сравнения, результаты бенчмарка этих процессоров и более новых, рассматриваемых к покупке (все в разгоне):
Таким образом, выбирая новый процессор, можно использовать эти данные, чтобы оценить выигрыш в быстродействии.
Тестовый стенд
- Свежеустановленный Windows 10 (не захламленный всяким мусором)
- Самый дешевый китайский SSD
- Видеокарты GT 210 и GTX 460
- Проект Tap Tap Builder (мобильная игра для Android и iOS), суммарный размер ассетов около 500 Mb
Тестовая методика
Методикой это назвать можно с натяжкой. Берем секундомер и запускаем следующие операции:
- загрузка Windows 10 (с момента включения блока до появления рабочего стола)
- пересоздание удаленной папки Library (с момента открытия проекта до появления окна редактора)
- сборка игры под Android (с момента нажатия кнопки Build до появления APK)
- Параллельно будем смотреть на загрузку CPU в AIDA64.
Загрузка Windows 10
- E5 1660 загружает систему за 21 секунду
- i5 2500K загружает систему за 26 секунд
Поскольку загрузка ОС — это по большей части лишь копирование файлов с SSD в оперативную память, система загружается в обоих случаях очень быстро (чай завариться не успевает). Разницу в несколько секунд можно списать на время включения материнских плат (разные сокеты, разные BIOS).
Пересоздание удаленной папки Library
Удаленная папка это не та, которая далеко находится. Я ее просто удаляю, чтобы Unity выполнил повторный импорт проекта (функции Reimport не доверяемся).
Первым в бой идет i5 2500K:
Результат 5:43. Процессор практически все время трудится на максимальной частоте 4700 Mhz, однако на 100% не загружается.
Затем очередь E5 1660:
Результат 5:53. Процессор работает, не напрягаясь, а частота лишь изредка достигает максимума в 4200 Mhz. Средняя загрузка процессора около 12%.
О чем говорят эти результаты? 5 минут в обоих случаях это довольно долго. i5 2500K не сбрасывает максимальную частоту, но при этом не загружен на 100%. E5 1660 старается использовать все ядра, и поэтому снижает частоту до 3600 Mhz (но при этом средняя загрузка очень низкая).
Остается предположить, что первому не хватает потоков, а второму частоты, поэтому оба процессора показывают одинаково плохой результат.
Сборка проекта под Android
Снова начинает i5 2500K:
Результат 2:50. Работает на максимальной частоте, а загрузка ядер временами достигает 100%. Будь их больше, результат бы улучшился.
Затем E5 1600:
Результат 2:50, абсолютно такой же! Частота все та же — 3600 Mhz, но загрузка ядер ни разу не достигает 100%. Хотя нагрузка определенно выше, чем при импорте проекта.
Выводы можно сделать абсолютно такие же, как в предыдущем тесте. Кроме того, i5 уперся в свой потолок.
Поменяем видеокарту
До сих пор работала GTX 460. В этом тесте я заменю ее на GT 210. Кто не знает, это самое днище среди видеокарт. Хуже ее может быть только ее отсутствие.
Импорт проекта для E5 1660:
Результат 5:38. Как и ожидалось, скорость операции не изменилась (разницу спишем на погрешность и сторонние факторы, например, работу Windows).
Оперативная память
У меня 12 Gb RAM, и ее использование при работе с Unity не превышает 50%. Таким образом, для разработки на Unity хватит и 8 Gb RAM. И параллельно еще сможете запустить фотошоп и ютуб.
Выводы
1. Для комфортной разработки нужна и высокая тактовая частота процессора, и большое количество потоков. 4-х потоков у процессоров Intel i5 явно недостаточно. Исходя из бюджета, можно рассмотреть 4-х ядерный i7 7700K, который очень любят геймеры или 6-ядерный i5 8600K, оба стоят в районе 250-300$. Если есть деньги, то можно взять и 6-ядерный i7 8700K, который стоит под 400$. Ryzen 5 1600X и Ryzen 7 1800X могут быть адекватной альтернативой за меньшие деньги, хотя и будут проигрывать Intel в максимальной частоте — 4 Ghz против 5 Ghz у Intel (в разгоне, конечно же). Использовать устаревшие платформы Sandy Bridge+, будь то i5, i7 или серверные Xeon 16XX и 26ХХ, имеет смысл только при ограниченном бюджете.
2. Вам не обязательно нужна самая крутая видеокарта. Особенно, если вы делаете мобильные игры. Так что оставьте топовые видеокарты майнерам. Я для замены своей GTX 460 выбрал GTX 1050 за 130$, чтобы Dark Souls 2 пройти еще разок.
3. Кроме того, рекомендую использовать SSD, поскольку Unity активно работает с файлами. Если вы ограничены в бюджете, можно взять даже самый дешевый SSD на 8 или 16 Gb, чтобы хранить на нем сам проект, а также установить туда Unity и все необходимые SDK.
Масштабируем блокчейн сохраняя децентрализацию с Failsafe Network
Это происходит потому что размер блока ограничен константным значением, а желающих вместить свою транзакцию в блок заметно больше чем раньше. Что вызывает конкуренцию за комиссию и ее естественный рост.
Логично, что увеличив блок мы сможем вместить больше людей а значит отложить проблему? С одной стороны — да — так поступил Bitcoin Cash вся суть которого сводится к увеличению блоксайза до 8Мб.
С другой стороны — нет. Об этом, и о разработанном блокчейне Failsafe который элегантно решает эту проблему — под катом.
1. С увеличением блоксайза становится сложнее содержать фулноду
Напоминаю, единственный правильный способ использования криптовалюты это быть фулнодой — иначе вы полагаетесь на картель майнеров чтобы он следовал правилам консенсуса. Майнерам/валидаторам же нужно максимизировать прибыль, и как только они почувствуют власть они начнут банить неугодных, создавать unspent transaction outputs из воздуха, и так далее.
Каждая нода верифицирующая каждое движение стейта — залог децентрализованной и честной сети. В последнее время стало модно говорить что simple payment verification это нормально и что мы так или иначе верим майнерам что они не совершают дабл спенд. Не будем в это углубляться — любой желающий может нагуглить почему крайне важно максимальное количество фулнод, и почему лэптоп должен всегда рутинно быть фулнодой, иначе происходит централизация сети вокруг state keepers, которые в какой то момент могут просто перестать раздавать новые блоки наблюдателям и превратиться в cross-signed paypal state, «с деньгами берущимися из ниоткуда и пропадающими в никуда, лишь бы подписи были».
За константу, возьмем average world internet connection — 1 мегабайт в секунду, и заявим что пользователь открывающий кошелек раз в неделю должен в лучшем случае ждать не дольше 10 минут чтобы синхронизироваться с остальной сетью. Это выходит как раз текущий bandwidth usage у Bitcoin Core. Подробнее про этот параметр который я окрестил weekly sync friction можно читать тут.
Вторая проблема блоксайза это то что даже у него есть практические лимиты.
Многие новые «псевдо» блокчейны любят заявлять tps (transaction per second) в районе 10 и даже 100к (например bitshares). Однако, начиная читать «fine print» про них можно увидеть что они предполагают gigabit connection и дьявольски мощные сервера. Очевидно, ни на каком лэптопе такое не запустить. Это пара десятков фул нод крутящихся в централизованном облаке, а то и вообще в одном датацентре, в которых от блокчейна ничего не осталось.
А нужно ли нам 100к тпс? Каждый решает сам, но я верю в sound money — циферки на экране которые я могу послать любому человеку на земле, и он примет их понимая их стоимость так же как и я, не парясь о объемах блока и платя мизерные комиссии. А значит надо чтобы такая система поддерживала абсолютно любой перевод стоимости для всего человечества. Грубо прикинув что есть 5 млрд entities (все платежеспособные люди + бизнесы) совершающих 1 транзакцию в день требует 58,000 tps. А если прикинуть что этих транзакций не 1 а 10 (мир интернет коммерции растет не по дням а по часам) то и все 580к. Такой объем среднего tps просто невозможно уместить on-chain, ни сейчас, ни через 10 лет.
Сам Сатоши наивно полагал в 2009 году что мощности компьютеров будут расти так быстро что off-chain масштабирование нам не нужно. Оказалось, что рядовому консьюмеру уже и так хорошо, а значит зачем стараться больше? Apple не собирается инвестировать в разработку 10 терабайтных айфоном с 1 гигабитным интернетом чтобы внутри можно было запустить блокчейн. Это реально, но для них в этом нет коммерческого интереса.
А значит работать надо с тем, что есть. А точнее даже с в сто раз меньшими техническими требованиями — ни один юзер не захочет держать лэптоп круглосуточно лишь бы успевать за сетью какого-то блокчейна.
Наоборот, фул нода должна быть маленькой утилиткой в углу системы, тихо сжирающая 1% интернет траффика, 1% пространства на диске и 1% процессорной мощности. Иначе она будет удалена — что собственно и произошло сейчас с биткоином и эфириумом. Запускать фул ноды на лэптопе стало практически невозможно, и все перешли на SPV кошельки а то и вообще вебсайты типа myetherwallet.com (который в любую секунду может быть взломан, заменить .js файлы и слить ваши приватные ключи).
А какие альтернативы?
По большому счету предлагаются 3 варианта. Sharding — когда блокчейн делится на шарды, и ваш клиент становится аналогом SPV при работе с чужими шардами, side chains/plasma где создается отдельный блокчейн который может быть «жирным» но обязан слать чекпоинты в главный чейн чтобы его можно было поймать и наказать. Оба варианта слабо увеличивают tps, хороши лишь для микротранзакций и плохо влияют на децентрализацию — про них мы не будем говорить. Третий же вариант это системы построенные на основе payment channels такие как lightning и raiden.
Пеймент канал по сути это объявление в блокчейне что два участника далее решают состояние баланса некого аккаунта между ними двумя, multisig на двоих.
В пеймент канале не возможен дабл спенд, так как он двух сторонний. И если я получаю комитмент на сумму Х (подписанная строка от другого участника) я на 100% уверен что я получу Х ведь он не мог больше никому их пообещать. Блокчейн же тут выступает роль арбитра, к которому обращаются когда нужно закрыть этот канал и каждому взять свою часть денег.
Существует очень мало людей которым имеет смысл открывать каналы между собой, так как все платят разным лицам. Поэтому логично предположить что система может приносить пользу только при существовании хабов. Алиса открывает канал к хабу, хаб открывает канал к Бобу, Алиса платит хабу, хаб платит Бобу, все довольны.
Именно эту стратегию считают основной в масштабировании биткоина — подробнее можно прочитать на сайте LN.
Lightning и ликвидность
Если же вдуматься в эту архитектуру, можно увидеть серьезный промах в модели мотиваций участников. Да, Алисе ничего не стоит открыть канал на 100 баксов к хабу, но для того чтобы хабу открыть канал к Бобу ему надо инвестировать свои собственные деньги, послав транзакцию в блокчейн.
Боб может быть эфемерным ботом, и это может быть единственный перевод в его сторону. Каналы имеют смысл лишь когда они использованы многоразово — сотни и тысячи раз, если же он используется редко то он убыточен для хаба.
Так же, у канала есть объем — те Алиса не сможет послать больше 100 баксов что есть в канале (иначе хаб теоретически просто не сможет их забрать из блокчейн контракта, ведь в нем только 100 и лежит). Та же проблема на выходе — если у хаба с Бобом канал только на 50 баксов, то Алиса не сможет зароутить платежи больше 50 баксов в сторону Боба через хаб — тк вместимость считается по минимальному каналу на цепочке, и хаб просто не сможет пообещать и послать криптографический коммитмент Бобу на более чем 50 баксов.
Это проблему я окрестил incentive / cost / capacity — у хаба нет мотивации открывать каналы без тщательного KYC (know your customer + anti money laundry), оперировать хабом очень дорого и нужно инвестировать собственные средства, и у выходных каналов хаба всегда ограничена вместимость а значит многие платежи просто провалятся (вы в кафе и от вас до владельца кафе не хватает $1 в объеме каналов — вы не способны заплатить несмотря на ваш собственный канал к хабу в 100 баксов). Подробно эту проблему я описал так же в этой статье.
Failsafe Network
Вот мы и плавно подошли к тому над чем я работаю уже полгода. Фс как концепт это и решение для масштабирования обычного блокчейна, но я так же разработал новый блокчейн с нуля, которое это решение включает в себя из коробки.
Демо https://failsafe.network/#install
Система берет за основу lightning network и добавляет возможность посылать деньги в долг.. Т.е. там где ЛН ложиться на лопатки и говорит что не найден route/capacity в каком то направлении в фс хаб просто обещает эту сумму своему пользователю, и это криптографическое обещание так же можно послать в блокчейн и получить по нему деньги (но при условии что хаб не взломан и имеет эти деньги).
Само подписанное платежное поручение мы называем delta — те отклонение вашего офчейн баланса от текущего ончейн баланса (aka collateral, insurance). В lightning используют название commitment transaction (тк то что вы даете хабу по сути валидная биткоин транзакция — у нас это не так, это спец форматированная строчка), в raiden (эфировая альтернатива, заточенная под посылку ERC-20 токенов) называет это balance proof.
Таким образом мы достигаем бесконечный скейлинг офчейн, сохраняя сам блокчейн маленьким, что не составляет труда быть фулнодой на лэптопе или смартфоне.
Теперь каждый участник сети не сообщает всем остальным о переводе за кофе или квартиру — вместо этого практически все платежи (кроме совсем огромных в миллионы долларов) должны проходить через хабы.
Каждый участник может выбрать 1 или более хабов с которыми он будет держать канал. Пока еще неясно как эти хабы будут создаваться, но наиболее логично что по географическому признаку. И так moscow hub может обслуживать всех жителей Москвы.
Как выглядит оплата?
- Алиса приходит в кафе и просит счет.
- Алиса касается телефона / сканирует QR, ее кошелек берет последнее значение дельты хранимое с местным хабом и уменьшает эту дельту на сумму покупки .
- Эта подписанная дельта шлется прямиком на сервер хаба с примечанием «переслать этому кафе У за этот инвойс Х).
- Хаб верифицирует изменение дельты и узнает какую же сумму Алиса платит. Убеждается что объем оплаты меньше или равен размеру канала (сама Алиса в долг платить пока не может.
Но это пока — кредитки в этой системе тоже предусмотрены) - Хаб ищет в системе открытый вебсокет в сторону кафе У, достает из своей базы данных последнюю дельту с этим кафе и увеличивает ее на эту же сумму минус офчейн комиссию (0.1%
в данный момент — в 30 раз меньше визы и пейпала) - Платежный терминал или смартфон владельца кафе получает новую дельту от хаба и примечание за какой инвойс пришел платеж. Если сумма инвойса и то насколько дельта была увеличина равны, инвойс помечается как оплачена. Алиса может идти.
Таким образом мы не только решаем проблему объема блока, но и делаем процедуру платежа предельно дешевой и моментальной — что идеально подходит для офлайновой коммерции и вполне приятное дополнение для онлайновой (никому не охота ждать по 30 минут 3 конфирмаций).
Хаб же в свою очередь должен делать умный машин лернинг на статистике дельт всех юзеров. Когда дельта равна -10 это значит хаб владеет 10 юнитами из канала данного пользователя. Когда дельта +10 значит хаб пообещал данному пользователю добавить в канал 10 юнитов.
Есть риск что хаб пообещает денег больше чем у него хранится в негативных дельтах — и поэтому хаб обязан делать ребаланс своих каналов как только они перевесят определенные суммы например <-100 и >+100.
Сам блокчейн превращается в легковестный снапшот страховок (insurance). Часть баланса будет insured — так же как и в биткоине этот баланс гарантирован и выживет даже после полного взлома хаба, а малая часть uninsured — обещанный баланс у некоторых пользователей.
.
После значительных колебаний у тех юзеров кто много потратил (послал негативную дельту хабу) забираются деньги и отдаются тем кто много заработал уже ончейн, и выполняется на компьютерах всех пользователей. Эти транзакции будут редкими и легковесными, в то время как офчейн проходят миллионы транзакций не оставляя и следа о себе внутри блокчейна.
Каждый будет видеть внутри своего кошелька у кого сколько денег хранится в хабе, а точнее „с хабом“ (в этом и главное отличие хаба от банка — деньги не принадлежат хабу, он лишь их временный держатель) — и получать из сети одни только ребалансы этих страховок с хабом. Но никто не будет знать кому, когда и сколько ты послал лишь финальный результат в конце недели что твой баланс уменьшился на $10,000.
Самое же крутое, что большинство пользователей почти не будут касаться блокчейна и избегут ончейн комиссий (которые так же как и в биткоине будут в районе 10-100 баксов) если они правильно структурируют платежные потоки вокруг себя (streaming money). Каждый полученный доллар будет направлен на аренду или оплату кредита — и размер дельты всегда стремится к 0 а значит почти весь баланс пользователя застрахован всегда и обладает теми же свойствами что и биткоин.
Все хабы существуют независимо друг от друга (как и ISP хабы в сети интернет), могут иметь каналы между собой с определенными лимитами риска (прямо как корреспондент счета в банках), и разделяют общий сеттлемент слой (что является заменой центрального банка). И вся эта система способна выдержать миллионы транзакций в секунду без ущерба децентрализации первому слою (на котором хранятся лишь страховки которые очень редко ребалансируются)
PS: написал и сам ужаснулся как все пропитано странными терминами и сложно описано. Заранее простите, концепт двухуровневый и весьма сложный, и много крутых фишек типа встроенных снапшотов и децентрализованной установки не вошли в текст — с удовольствием отвечу на все вопросы.
С системой как я уже сказал можно поиграться на failsafe.network а код прототипа есть на Гитхабе.
СТО: мечты сбываются? И другие доклады для тимлидов с HighLoad++
Докладчики в предыдущей части уже предупреждали будущих тимлидов о том, что подъем по административной лестнице снижает долю «технической» и «творческой» составляющих в работе в пользу мелких задач по управлению. Однако спикеры из второй части нашего обзора утверждают, что дальше будет только хуже. Больше административных задач и ответственности, меньше времени на непосредственную работу. Но если душа к этому лежит, не стоит упускать свой шанс.
Как я был тимлидом, а теперь — руководитель направления
Тезисы доклада
Найти себе заместителя — первостепенная задача каждого руководителя. В своем докладе Виталий Шароватов (компания Badoo) говорит о выращивании тимлида, но не с точки зрения самого «испытуемого», а с позиции недавно назначенного руководителя, которому срочно надо искать в коллективе потенциальную замену.
Почему в коллективе? Потому что спикер, как и его коллеги из первой части нашего обзора, считает, что инженерами лучше руководит инженер. Однако на эту позицию может подойти не любой технарь, поскольку для успешного лидерства нужно «отращивать» административные навыки. Путь по карьерной лестнице в сторону управленца представляет собой лишь один из возможных вариантов развития специалиста, и он нужен не каждому.
Виталий представил интуитивно выработанный, но хорошо формализованный подход к выбору, назначению и последующему сопровождению тимлида в команде, который поэтапно отсеивает неподходящих кандидатов. Вчерашним разработчикам такой взгляд понравится. С другой стороны, его подход показался нам очень «человечным» — на каждом шаге присутствуют разъяснения, как все это сделать комфортно для окружающих людей. К примеру, рассматривается процесс назначения нового руководителя с точки зрения ожиданий вверенной ему команды, а также последующее введение специалиста в курс дела.
Подход, предложенный спикером, требует от руководителя довольно много времени на начальном этапе. Виталий считает, что начинающего тимлида стоит в буквальном смысле вести за руку, выстраивая вместе с ним процессы и разбирая возникающие сложности. Однако эти затраты прикрывают риски — чинить «сломанную» кривым руководством команду потом будет гораздо дороже.
Беседа наполнена практическими советами по всем аспектам пути новоиспеченного тимлида. Но, в отличие от докладов первой части, советы предназначены не для самого тимлида, а для его руководителя.
Одна из основных идей, которой спикер уделяет много внимания, создание подобия советской картотеки с регулярно обновляемой информацией о сотрудниках и даже внутренним скорингом. Попутно Виталий разобрал важные для тимлида человеческие качества, снабдив все это простыми жизненными примерами.
Все подробности в видеозаписи.
Как убить технаря в руководителе
Тезисы доклада
Хотя инженерный бекграунд важен для руководителя разработчиков, в некоторых ситуациях он будет мешать эффективному управлению. В своем докладе Александр Трофимов и Дмитрий Мачехин (Лаборатория Касперского) рассказывают о том, какие «технарские» привычки будут мешать разработчику, только начинающему свой путь по административной лестнице.
Для наглядной иллюстрации навыков, необходимых для руководителя, Александр предложил присутствующим нарисовать картинку по его устному ТЗ. При просмотре доклада рекомендуем не пропускать эту часть, а попробовать поучаствовать. После того, как в презентации появится изображение того, чего же на самом деле хотел заказчик, ряд аспектов работы руководителя удастся в буквальном смысле прочувствовать на собственной шкуре.
Основная мысль доклада заключается в том, что став руководителем, специалист перестает отвечать напрямую за систему — он отвечает за людей, создающих ее. И в непривычной ситуации он может попасть в одну из нескольких стандартных «засад». В докладе речь пойдет о двух из них — тех, в которые попал спикер: о попытках делать работу за криворуких (по мнению новоиспеченного руководителя) подчиненных и о злоупотреблениях полномочиями, то есть стремлении переделать весь «монастырь» под свой «устав».
Главный посыл доклада заключается в том, что надо быть умеренным в своем желании все сделать по-своему как с точки зрения технологий, так и с других позиций (графика работы, детализации менеджмента). Людям надо доверять, учиться делегировать, а свои силы направить на более высокоуровневые задачи.
Несмотря на этот спойлер, рекомендуем все же посмотреть видео, так как абстрактный совет «не мелочиться» запоминается гораздо хуже, нежели цепочка ярких личных примеров с разбором результатов, полученных на реальной команде.
Кроме видео, мы также сделали полную расшифровку этого доклада.
СТО: мечты сбываются?
Тезисы доклада
Доклад Романа Ивлиева (ivliev.info) — о том, как на самом деле выглядит работа технического директора (CTO) глазами человека, прошедшего все административные уровни, начиная от обычного технаря.
С нижних уровней карьерной лестницы иногда кажется, что CTO занимается непонятно чем, а ведь у него в руках столько хорошего: целая технологическая команда, которая может решать сложнейшие задачи и готова пойти за него и в огонь, «и в воду, и в воскресенье на работу» (по выражению самого спикера). Однако, как рассказывает Роман, к команде, возможности принимать свои решения и нести за них ответственность, «бонусом» идут множество сопутствующих дел — кадры, бюджет, бесконечные совещания с руководителями других подразделений, вопросы ЖКХ (куда и как посадить нового сотрудника) и самая страшная аббревиатура — ФОТ. Техническому директору приходится учиться объективно оценивать людей, следить за рынком, искать способы удержать хороших специалистов и решать кучу других вопросов.
Начав с такой «бочки дегтя», спикер рассказал про типичные «болезни» инженера на месте CTO. О том, какие качества лучше оставить в прошлом, а какие навыки, наоборот, подтянуть. О том, насколько тяжело бывает продвинуть техническую идею в компании через разговоры о сроках, рисках и бюджетах. И о том, что результатов работы CTO не видно, даже по сравнению с тимлидами (в докладах первой части обзора был разговор о том, что в отличие от рядового разработчика, тимлид не имеет возможности быстро оценить результат своих действий; и чем выше уровень — тем это ярче выражено). Зато ошибки технического директора видны почти сразу.
Весь рассказ наполнен очень жизненными примерами из собственной практики Романа.
В целом доклад лишний раз показывает, что с верхушки административной лестницы взгляд на технические проблемы совсем иной. Но так как это не руководство всей компанией, несмотря на то, что CTO видит множество факторов, он не всегда может оценить их влияние на ситуацию в целом.
Доклад будет полезен тем, кто движется вверх по административной ветви развития. Как отметил Роман, если руководитель хочет вернуться в программирование, делать это надо как можно быстрее, поскольку технологический стек меняется с невообразимой скоростью. И этот «взгляд изнутри» поможет лишний раз оценить специалистам, хотят ли они такого развития.
Сопротивление в работе команды и его «симпатичные» сценарии, приводящие развитие команды в тупик
Тезисы доклада
Вместо заключения — небольшое погружение в психологию командной работы. Несмотря на хитрые методики кадрового отдела по оценкам психологической совместимости, тимбилдинг и прочие моменты, всегда есть что-то, что мешает команде развиваться. Доклад Александра Зиза (Алетейя Бизнес) повествует о том, какие типовые проблемы встречаются в 100% команд разработчиков (и не только).
Доклад Александра ценен тем, что несмотря на огромное количество теории по вопросам командного взаимодействия — корневые причины перечисленных проблем давно известны — фундаментально они не решены. Чтобы разобраться в этом бардаке, нужны практика и опыт. А заодно понимание, что именно активнее всего проявляется в ИТ.
Интересно, что российская прописка компании также добавляет своей специфики.
Однако не будем заниматься пересказом — за подробностями рекомендуем обратиться к видеозаписи доклада.
По ходу беседы специалист рекомендует литературу, ссылается на исследователей — в целом будет, что почитать. Например, «Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте» (Эдвард Йордон) — про системный уровень работы с командой, хотя и эта книга многое оставляет за кадром.
Однако спикер предостерегает от самостоятельных действий. Для сохранения комфортной атмосферы работы все психологические беседы с сотрудниками он рекомендует вести со стороны — с помощью приглашенных консультантов. А что касается информации из доклада и литературы — они для целей саморефлексии.
Для тех, кто хочет не размышлять, а действовать, Александр предлагает пошаговую стратегию развития из пяти пунктов (в правой нижней части слайда):
Дублируем ссылку на опросник. Но прежде чем бросаться его распечатывать, посмотрите сам доклад.
Друзья, хотим напомнить, что очередной этап обмена опытом по тимлидерству и управлению пройдет уже в начале февраля в рамках конференции TeamLeadConf 2018. А на сайте конференции вы сможете найти видеозаписи десяти наиболее интересных прошлогодних выступлений.
Кстати, ещё можно впрыгнуть в уходящий поезд и подать доклад. Что сказать? У нас есть результаты мозгового штурма на эту тему.