Tag: Немечек

Copyright - https://waitbutwhy.com/2018/04/picking-career.html

Студенти, стаж и работа

03/04/2019 / / 2 Comments

Миналата седмица изнесохме две лекции респективно в Икономически Университет и Технически Университет във Варна.

Поговорихме доста за компанията, за условията, но най-важното бяха въпросите. Ще се постарая отговорите да са универсални, защото така или иначе статията не е с рекламна цел.

 

Колко опит трябва да имам за да започна стаж?

За започването на стаж обикновено компаниите търсят студенти (или ученици), които имат интерес в сферата, но професионалния опит не е задължително изискване. Ако ви е интересно и сте правили задачки във вас или в университета и имате някакъв фундамент значи сте готови да се гмурнете в занаята.

Колко време ще съм стажант?

Обикновено стажовете продължават между 3 и 6 месеца (така е в Немечек например), като след като приключи предварително уговорения срок изборите са два:

  • Започване на Junior позиция в компанията:
    • Очакванията към вас са оправдани и двете страни са доволни. Следват промяна на възнаграджението (което трябва да е упоменато в договора ви още като започвате стажа си) и други придобивки (ваучери, втори монитор или каквото друго предлага компанията). Освен това четири други неща ще се променят:
      • Задачите ви ще станат по-отговорни и шанса да имате парче код, което ще работи при клиент е много вероятно. Вашите ментори вече няма да са с вас на всяка крачка, но ще продължат да бъдат на разположение. Тогава трябва и смяна на начина на комуникация – въпросите да са по-малко, по-структурирани и да сте се подготвили сериозно преди да ги зададете;
      • Вероятно ще имате втори изпитателен срок – това също е честа практика и отнема време. Не бъдете нетърпеливи, защото за няколко месеца/година ще влезете в бранша и оттам всичко остава във вашите ръце;
      • Бъдете самоинициативни – ако някой процес не ви хареса или имате идеи за развитие, курсове, споделяне на добри практики или каквото и да е било друго не се срамувайте, а говорете с вашия Team lead.
      • Бъдете готови да помагате на другите около вас без значение от това дали не са от 20 години в бранша или са стажанти. Бранша ни е толкова мащабен, че всеки може да даде ценна троха знания на всеки около него.
  • Прекратяване на Стажа ако една от страните не е доволна от другата:
    • Ако не се харесате с компанията в която работите и решите да я сменяте, го направете по възможно най-коректния начин. Това е първата ви компания и е важно да се разделите в добри отношения (без значение дали са били добри с вас или са били абсолютните задници). Пък и не е рядка практика HR-ките да звънят на предни фирми, в които сте работили за да разпитат;
    • Ако сте доволни от компанията, но не и от заплащането винаги можете да договорите. Съвет от мен е при преговори да се подготвите предварително с план в краткосрочна и дългосрочна перспектива. Това включва подобряване на hard skills (например ученето на нова технология) и по-трудното – работа по някой soft skill (комуникация, работа с екипа и т.н.);
    • Ако са ви пръснали от работа и това е причината да напуснете – тогава expectations management-а и на двете страни не е сработил добре. За това в началото при даването на задачите ако усетите, че има вероятност да не се справите разпитайте, прочетете повече и преговаряйте. Ще се учудите колко отворени са хората. И е нормално да не дадете супер точен estimation. Това идва с опита.

Колко време ще ми е нужно да стана Mid и Senior?

 

Всяка компания има политика за определяне на това кой в какъв seniority level e. За да придобиете представа ще дефинирам четирите основни нива:

  • Intern (стажант) – често млад и надъхан студент или ученик, но може да е човек, който сменя бранша. Обикновено има човек, който се грижи за него – ментор, който му дава задачи, оценява го как се справя и т.н. Очакванията към него са да е нахъсан и да му се учи, да се адаптира бързо към средата и да му е интересно;
  • Junior – стъпка над стажанта, вече може да се чувства, че опита му започва да става професионален. Задава си въпроси, които като стажант не е можел да си отговори ясно (например накъде да копае – frontend или backend, някоя конкретна технология или каквото се сетите). Задълженията му нарастват и вече има задачки за него, които не са тренировъчни, а реални. Трябва да можете да комуникирате ясно и стегнато и да знаете на кого да зададете въпросите си. Очаква се от вас ако имате мнение по някой въпрос касаещ кода, проекта или процесите да ги обсъдите с вашия Team Lead. Очакванията са да си задържите и засилите интереса към това, което правите и да се стремите да сте по-добри;
  • Mid – вероятно най-често срещаната позиция в бранша. Това са хора с изграден вече професионален опит, които имат добър фундамент, справят се с много голяма част от задачите, които има за правене по проекта. Те могат да виждат голямата картинка, да разбират бизнеса и да работят самостоятелно. Не е рядкост към Mid (програмист, QA, PM, изберете си сами) да закачат някой стажант или junior като човек за помощ и подкрепа, а понякога и направо като ментор. Очакванията са да са самоинициативни и самодостатъчни, да комуникират с лекота с всички членове на екипа и да знаят как работят нещата отдолу, да могат да се справят със заплетени проблеми и както обичам да казвам – да са настъпвали възможно най-много мотики за да знаят какво и къде да правят;
  • Senior – освен солидната техническа грамотност трбява да са мотивиращи и лидери (не е задължилно да са lead-ове), да могат да помагат на другите, да дърпат проектите напред и да бъдат хората, които като някой има въпрос да са там и да имат желание да помагат. Тези хора Виктор ги нарича oracles. Освен това дълбокото разбиране на проблемите и ясната позиция при решаването им са много важни. Комуникация с клиенти също е често срещано. И накрая, но не на последно място senior хората трябва да са израснали вътрешно – да са спокойни и да знаят как да приоритизират.

Както виждате за всички позиции човек трябва да е надъхан, да му е интересно и да рови. Ако нямате подходящия attitude сте обречени на вечно мънкане и бърз бърнаут.

Какво трябва да мога и какво ще науча освен техническата част?

Понеже обичам bullet points:

  • Трябва да се научите да комуникирате с хора – да сте спокойни и да задавате правилните въпроси, да можете да говорите с лекота както с програмистите, с вашия team lead и ако щете със CTO-то ви. Задаването на правилните въпроси носи удовлетворение и ефективност и в двете страни, но значи и че трябва да се научите да си структурирате въпросите правилно както и да четете предварително преди да задавате такива;
  • Научете се да … учите – в нашия свят много често се налага да навлезем много бързо в някоя непозната за нас технология и това е напълно нормално. И виждам как хора научават в движение Go или React и се справят отлично. Тайната е това, че тези хора имат стабилен фудамент на който да стъпят и разбират и методика на учене;
  • Да се стремите да виждате голямата картинка. Януари тази година бяхме с екипа в САЩ и там се срещнахме с нашия CEO и съответно имахме време да си поговорим на дълго и на широко. Още от първото изречение видях, че моя и неговия мироглед са толкова различни, че чак е стряскащо. Той гледа с няколко години напред, усеща кога идва нещо голямо и каква е голямата картинка. Аз към този момент (в аспекта на текущия ни проект) се грижих за абсолютно микроиоскопичните детайли. Такива разговори действат отрезвяващо и карат човек да се замисли за това;
  • Да се научите да вършите работата си по определен начин. Както във всеки проект текат различни процеси, които го държат стегнат и праволинеен така и вашата работа трябва да се основава на нещо подобно.  Всеки обича чистото и подредено бюро, но не всеки се замисля дали е проблем това, че работим едновременно по 6 различни задачи и имаме 145 отворени таба на браузъра.
  • Работа в екип – в идеалния случай екипът се събира като части от пъзел – лесно и безпрепятствено. Понякога обаче е все едно сте призовали 8 демона, които се бият с лопати през няколко минути. Без значение от коя страна сте работата с хората във вашия екип трябва да е първо на професиоанлно ниво и да оставите на заден план личните ангажименти. Защото ако в пъзела има една част, която не пасва тя обикновено бива изхвърлена. И е признак на зрялост желанието за подобряване на отношенията в екипа;
  • Да държите на критика. Ако сте програмист ще има цял екип от малки демони, които ще тестват вашата работа и ще логват къде адекватни, къде не проблеми, ще има колеги, които няма да харесат вашия pull request и ще пишат коментари, много коментари. И ще изглежда, че всичкие са гъзове и че не ви харесват и че изглежда, че ви казват, че за вас ще е по-добре да пасете овце/крави на село, но това не е така. Всеки в един работещ екип има една основна цел – проекта да върви напред. А за да върви напред качеството на работа на всеки един от екипа трябва да е на високо ниво. Не забравяйте, че качеството и ефективността на всеки екип е равно на този с най-малко опит;
  • Бъдете пич (пич е state of mind, а не полово определение, моля, моля!) – когато човек е пич нещата вървят по-лесно. Дребнавостта, нуждата за внимание на всяка цена и всякакви малки злободневни неща могат само да подразнят колектива.

 

И пак си бях обещал да не правя 100 страници пост и пак не ми се получи :)
Надявам се да съм бил полезен. Ако имате въпроси ги задавайте под статията в секцията за коментари.

 

P.S. Споделям с вас страхотния материал на WaitButWhy.com – How to Pick a Career (That Actually Fits You). Отделете му време, съветите са брилиантни.

ISTA 2018 live blogging, day 2

16/11/2018 / / 0 Comments

Добро утро.
Винаги е приятно да влезеш в зала с десетки хора, които говорят за Agile, код и тестване.

 

Всичко започна с лекцията на Mathias Verraes – “Design Heuristics”

Това, бога ми, беше първия keynote speech без презентация, който гледам. Чувството е като онези push-up bras. Всичко беше ок, но нещо липсваше.

Аз лично се изгубих напълно още в началото.

 

Hindsight lessons about API testing
Viktor Slavchev

 

Да слушаш тестинг трола винаги е удоволствие. Дали е заради лекотата с която засажда идеи в главите ни или за интересните теми или заради братата, не знам, но при мен се получава.

И да не звуча тенденциозно мога да го хейтна (без хейт не може!1!!) – тази брада трябва да расте, по вързможност до колената! Край на хейта.

Сега, сериозно.

Лекцията му започна с препрепълнена зала и хора седящи по земята.

Първо да уточним думата hindsight. Това е “умението” да разбираме някакво събитие или ситуация само след като то се е случило. И един много подходящ пример “With hindsight, we would recommend exactly the opposite.”

Виктор каза нещо познато, което трябва да се казва много по-често и да се използва – “Tools don’t make software (tools are not a solution). You’re the one who solve the problem”.

Преди да влезем в контекста на API тестинга трябва да обясним какво е web service и Виктор го обясни по интересен начин:

Web service-а е като комуникацията със сервитьор*:

  • Правите поръчка (request);
  • Получавате отговор (от типа да/не) (status code);
  • Получавате това, което сте поръчали (data, result)

Извън контекста на презентацията на Виктор – примера със сервитьора може да се използва и при security testing-а като му поръчаш да ти сервира ‘, *, NULL, 0 OR 1=1, шкембе с крутони и т.н. И после следим резултатите.

 

Относно точката за status code-а – понеже статус кодовете наистина са много и е хубаво да знаем поне основните най-лесния начин за това е да видите http status cat. От там аз научих повечето :D

 

Няколко неща преди да започнем с API тестовете:

  • Документацията не е винаги е пълно описание на продукта. Особено автоматично генерираната, outdated или зле написаната документация. За това трябва да мислим, да идентифицираме да  намерим нашия testing oracle (дефиницията си я намерете в блога на Виктор), да задаваме въпроси;
  • Настройката ви при писане на тестове – не пишете тестове, които минават, светят в зелено и еднорози скачат по репорта, а тестове, които тестват функционалност (понеже тук може да се говори много можете да пишете коментар в този блогпост или в поста на Виктор в неговия блог);
  • При API тестинга често забравяме да тестваме истински сценарии, а не само кой call какви отговори връща;

 

Кои тестове си струва да автоматизираме

  • Всички тестове, които връщат грешен response code (status code checks);
  • Всички тестове, които връщат грешни данни (structure checks);
  • Всички тестове, които не връщат никакви данни;
  • В добавка – освен единични, изолирани тестове е нужно да правим тестове по цели сценарии, знаете, но да кажа.

 

Status code checks – плюсове и минуси:

  • Плюсове:
    • Пишат се бързо и лесно;
    • Много дефинитивни;
    • Работят като sanity/smoke тестове.
  • Минуси:
    • Много повърхностни;
    • Трудно получаваме някаква полезна информация ако използваме GET методи (получаваме само status code без никакъв контент);
    • Status code checks сами по себе си не дефинират сериозни проблеми;

 

Structure checks – плюсове и минуси:

  • Плюсове:
    • С тях лесно може да проверим данните, които получаваме (no shit, Sherlock);
    • Тестовете могат да са много конкретнил
    • Ако използвате Codecept, например, можете да използвате regex.
  • Минуси:
    • Тези тестове са използваеми само за тестване на съдържание;
    • Трудни са при тестове на променливи данни;
    • Не са лесни когато имате deep nesting/дълги респонси.

 

Scenario checks – плюсове и минуси:

  • Плюсове:
    • Много близки до потребителското изживяване;
    • Използваеми при намирането на integration problems;
    • Могат да бъдат изпозлвани като леки regression suits;
    • Когато пишете scenario checks приемайте API-то като приложение (не ме целете с домати, но помислете за това). Много по-лесно е да измислите някакъв flow и да работите по него..
  • Минуси:
    • Бавни за писане/изпънение;
    • Изискват добра абстракция;
    • Трудно е да се каже кога са достатъчни

Както е писано неведнъж – при писане на тестовете използвайте ААА метода – arrange, act, assert. Това е достатъчно. Ако обаче се оплетете в морето от arrange/act-ове драмата ще е по-голяма от тия в индийските сериали.

Сега като си препрочетох описанието с тази кирилско/английска плетка не ми звучи толкова добре колко я чух, може би трябваше да я опиша на английски.
В блога на Виктор има голяма част от това, което каза на лекцията така, че смятам ще ви е интересно.

 

 

Sales Skillz for IT People
Iancho Dimitrov, VP Innovation, Strategic Clients & Business Development, Musala Soft

Доста извън моя интерес реших да участвам в лекцията на Янчо Димитров, който беше представен като легенда. Сигурно е.

Разакза ни малко за продажбите като имаше две интересни попадения:

  • “Sales are not bad thing if done right”;
  • “People don’t want a quarter-inch drill, they want a quarter-inch hole” Ted Levitt.

 

Why Teams and Culture Matter: Leadership lessons – Vasil Popovski

Преди години слушах за пръв път Васил Поповски на едно от първите издания на ISTA. Тогава той работеше за VMWare и тогава и сега разказваше супер интересните неща. И понеже този път няма да мина през превеждането на термини и презентация ще е на английски.

 

 

Google have quite interesting project called project Google Aristotle. With that in mind Vasil gives us couple of vision about what’s the most important thing in team:

5) Impact – team members think their work matters and creates change;

4) Meaningful work – is personally important to team members;

3) Structure and clarity – team members have clear roles, plans and goals;

2) Dependability – team members get things done on time and meet Google’s high bar for excellence;

1) Psychological safety – team members feel safe to take risks and be vulnerable in front of each other.

 

How to build a great team:

  • Team is not family – family is structure that is inherited, you cannot make changes there;
  • Lead the team, do not manage it – lead people, manage projects. Manager says “Go”, leader say’s “Let’s go”;
  • Foster a culture – culture is the shared core values, practices and beliefs of the team members.
  • Integrity is what you do when no one is watching

 

Hiring:

  • Hire for cultural fit;
  • Prefer skills over knowledge (skill is to know how to apply knowledge);
  • How many interviews you do as company – Google make a survey (how much interviews to hire someone) – fourth interviews was enough to predict a new hire’s performance with 86% confidence. After the fourth interview the accuracy of the mean score increases by less than one percent. More info can be found here
  • In Leanplum for example one backend developer goes trough next interviews:
  • Algorithmic
  • Coding/OOP
  • Design
  • Cultural fit
  • For Leadership skills

Performance management:

  • A single negative employee or bad performer can cause a 30%-40% drop in a team’s performance.

QA: Challenge Accepted 4.0

14/02/2018 / / 0 Comments

Ще се кюейваме, ще се аксептваме и ще се челинджваме на 21.04.2018 година на QA: Challenge Accepted 4.0. Акнетата за лекторите е пусната (Секция “Гласувайте за лектор“) и има 20+ желаещи да заемат челни места и да говорят там.
Аз съм един от тях. Ще говоря за jMeter и как да направим eye candy (и разбираеми!) графики с Grafana и InfluxDB, сигурно пак ще си съборя VPS-а по време на демото (been there, done that) така, че сигурно ще напомпам още малко marvin да преживее и това извращение върху него и така.

 

Едно е сигурно – дали ще говоря или не на QA: Challenge Accepted лекцията ще бъде подготвена и при първа възможност ще я разкажа, сигурно пред колегите в софийския офис на Немечек.

 

И още нещо, последно – ако гласувате ще ви помоля да го направите честно. Има много интересни лекции, интересни неща за които ще се говори и си заслужават да бъдат чути.

Равносметката 2017

31/12/2017 / / 0 Comments

Мина още една година. И по навик казвам нещата, които не съм направил първо, защото са по-важни.

  • Не водих лекции в Социалната Чайна. Преди няколко месеца излязоха открито и казаха, че парите им не стигат. Тогава се свързах с тях и говорихме да водя лекции в тяхната зала, а приходите (всеки плаща колкото реши) да отиват в Чайната. По същото време смених работата и реших да забавя нещата за да мога да се концентрирам върху нея;
  • Почти не снимах. За поредна година;
  • Почти не танцувах;
    • Нямам нито едно представление за годината.
  • Не говорих на TEDx. Темите ми щяха да бъдат свързани с депресията или Quality Assurance in real live;
  • Не говорих на WordCamp Varna 2017. Предложените ми теми бяха за security и performance testing. Не ги одобриха;
  • Почти не свирих;
  • Не карах колелото точно колкото исках. За това вече писах;
  • Не четох толкова, колкото исках;
  • Не писах толкова, колкото исках.

 

Нещата, които се случиха:

  • Започнах нова работа. За момента това е най-доброто място в което съм работил в съотношение колеги/проект/условия. Компанията е Немечек;
  • Направих моето Голямо Каране. До половината. Три дни интензивно каране и общо 264 км, спане в колата, катерене на връх Ботев, ядене на малини и ягоди на средата на нищото;
  • Случи се това. И близките ми за здрави и повечето дори са щастливи. Повече не мога да искам. Дори и котката Иво е жив и здрав (и дебел);
  • Изкарах 2 дуатлна (Злати се включи във втория и го изкара също), на единия дори и завърших в контролното време. Имам си и медал!
  • Пътувахме със Злати много. Обикаляхме из България, а тази година направихме и няколко пъти Варна-София-Варна със самолет;
  • Изкачихме връх Ботев за ден и спечелих от габровец 10-тина бири;
  • Говорих в WordPress meetup Varna за “Security of WordPress”. Получи се много добре;
  • Говорих и в “ИТ Форум” в Технически Университет Варна. Там организацията беше зле, след като си написах лекцията после 5 (!!) човека от предната фирма в която работих я редакритаха, рязаха, добавяха, осакатяваха докато не стана една страхотно скучна лекция типична за скучно-университетските и/или корпоративни среди. И имаше 10 човека (заедно с лекторите);
  • Говорих във “Вечер на таланта” за моето Голямо каране. Беше интересно, даже има и видео как фъфля;
  • Говорих в “EU Code Week Varna 2017” – беше най-класното и посещаемо събитие провело се в зала “Black Sea Hall” на хотел “Черно Море”;
  • Месец по-късно говорих в “Zara Code Week 2017” поканен от Венко Добрев. Беше най-сърцатото събитие, срещнах ценни хора, имаше крайно черен хумор вечерта преди моята лекция, заразих се от ентусиазма на Орлин. Абе беше страхотно преживяване;
  • Започнах да се заигравам с микроконтролери. За момента съм загърбил Raspberry Pi-то и си играя с ESP8266 (контролер с 80 Mhz процесор, micro USB захранване, вграден WiFi, I2C, etc.), DH11 (датчик за температура, влажност и атмосферно налягане), BSP280 (като DH11, но много по-точен и производство на Bosch) и голямата ми гордост – SDS011 (датчик за твърди частици). Като сглобя всичко това ще се включа в Air Bulgaria да следим в колко мръсен въздух живеем;
  • marvin е още жив. Покрай него научих супер много за системната администрация и как работи отдолу nginx. Нико, Владо – благодаря за помощта, която ми дадохте през времето когато го омазвах солидно;
  • Тръгнах да чета Хари Потър, до момента съм към края на петата част – “Хари Потър и Ордена на Фениска”. Четох и Бакман, Весела Тотева и Агата Кристи. Следващата година ще дочета Потъра и после – Глуховски. И повече от 9 книги за годината(срам, срам…);
  • Отидохме на Hills Of Rock, счупихме главите и си изкарахме потресаващо добре.

  • Не мога да повярвам колко дълга ми стана косата.

Нещата, които ще ми се случат:

  • Да направя каквото мога за Чайната;
  • Да правя хората по-добри. Винаги съм вярвал в споделянето на знания и ще продължавам да го правя докато мога;
  • Да чета приказки в дома за деца лишени от родителски грижи;
  • Да се случи моето Голямото каране 2 – този път 500+ км за седмица, вероятно пак сам;
  • Силна бреветна година – 200км, 300км (евентуално 200+300 във Варненски бреветен уикенд) и ако успея да вляза във форма – и един 600 км (400 е за ден, а 600 има време човек да поспи 2-3 часа за това казват и че е по-възможен);
  • Дунав Ултра – много се надявам да успея да участвам и да финиширам в контролното време;
  • Да изкарам първия си мартон.

 

Нещата, които заболяха:

13.12.2017

15/12/2017 / / 0 Comments

Днес бяхме на Коледното парти на Немечек. Беше добро, но няма да задълбавам в това.

Две неща се случиха този ден за които научих след като се прибрах в нас:

  • Орлин писа, че Ана Борисова си заминала на този ден. С Ани не бяхме супер близки, но се познавахме от варненските милонги, които посещаваше от време на време. Беше грациозна, вдъхновяваща, лека като перо и прощаваше всеки път като я настъпя. Не знам какво я е отнело от нашия свят, но се надявам да не я е боляло;
  • Колоезденето е един от най-тежките спортове в света. И много хора с крайни амбиции се опитват да бъдат на върха. А този връх в покрит със спринцовки и всякакви жалки опити едни да станат по-бързи от други рискувайки живота и здравето си и най-вече – колоезденето в очите на феновете. Тръгнах да пиша за Ланс Армстронг, но се отказах. Примери можете да видите в Wikipedia и списъка им с допинг скандали в колоезденето. Списъка е толкова голям, че се отвратих от професионалната част на този спорт. Anyway новия допинг скандал се завъртя около Крис Фрум, три пъти печелил Тура  и десетки състезания и rock star в съвременото колоездене.

 

И малко във връзка с втората точка – ако не сте гледали Tour de Pharmacy ви го препоръчвам.

08.12.2017

10/12/2017 / / 0 Comments

Никога няма да свикна да се возя в софийските трамваи. Цялото това блъскане ми идва в повече.

В офиса мина доста добре деня, а вечерта излязохме да пийнем по една – две бири с колегите. Станаха три – четири. Не знам как сервитьорката не ни изгони заради крайно специфичния фаталистичен черен хумор с нотки на извращения. Много се кефя с какви хора работя!

Утре е събота и мисля, че ще мога да се наспя най-накрая.

 

In other news:

02.12.2017

02/12/2017 / / 0 Comments

През деня обикаляхме по задачки и привечер тръгнахме към летището. Полета беше в 21:55. Времето не беше най-страхотното и имаше доста турболенция на моменти, но пък стигнахме успешно в София :)
Бяхме посрещнати от 2 спящи бебета и сестрата на Злати.
Утре се надявам да направим една разходка и си чакам снега!

ISTA 2017 live blogging day 1

16/11/2017 / / 0 Comments

ISTA 2017 ден първи

 

“Innovate, automate, accelerate” – Birger Thorburn CTO на Experian

Доста интересна и надъхваща реч относно бързото развитие на Expirian, която се занимава и с data analysis, няколко огромни цифри и ме накара пак да се замисля за сигурността ни онлайн. Това беше един страхотен пример как се води презентация пред хора – много добър начин на изразяване, слайда с данните беше представен по правилния начин (а не да се изчете всичко дословно), посланието от презентацията стигна до (повечето от) нас.

 

“The new leaders of quality” – Lyudmila Labova from Paysafe

Людмила говори за качеството, за quality measurements, non-measurable quality и best practices, говори доста за компанията в която работи. Споменава за това, че използват SonarQube. Като цяло лекцията е много основна и не научих много нови неща от нея.

И формулата за успеха на PaySafe е: V x D x F > R (Vision x Discomfort x First steps x Resistance). Ако това ви свърши работа намерете Любмила и я черпете едно.

 

Лекцията приключи 20 минути по-рано и имах време да вляза към края на:

“Security, Big Data and other challenges to the IoT” – Martin Harizanov от Visteon

Мартин Харизанов ни говори за сигурността в IoT и разказва за векторите на атака (които по дефиниция са почти същите както и на други real-world системи) като brute force, DDoS, после за превенция – client/server/OS updates, FOTA (firmware-over-the-air), monitoring и т.н. Накрая пак ни напомни, че абсолютно сигурни системи няма (може би освен тези, които са offline?). След това поговори за Big Data в IoT. Каза, че CISCO са излезли с доклад, че до 2020 година ще има около 20 милиарда неща (игра на думи от internet of things). Forbes пък са предвидили, че IoT трафика ще достигне 600 ZB (600 трилиона гигабайта) през 2020.

Note – тук отварям една голяма скоба:

  • Проверих твърдението, че до 2020 г. ще има ~ 20 милиарда IoT devices. Доклада, който намерих е от 2011 година и на страница три се споменава цифрата от 50 милиона устройства;
  • Доклада на Forbes относно твърдението, че до 2020 IoT ще генерират ~ 600 ZB е коректен, но написан в статия от преди точно година (13 Ноември 2016);
  • Тези статистически детайли не знам колко могат да бъдат прогнозирани, но ще следя с интерес какво се случва на IoT пазара.

Мартин обръща внимание на данните и трафика, които IoT могат да генерират. Всички ние взимаме трафика за нещо не толкова важно, но истина е, че той трябва да се пести. Разказа ни също и за няколко неща, които могат да ни помогнат като например това, че не всички данни трябва да се запазват и измерват, може да използваме агрегация (статия за data aggregation от IEEE), “Cold” data (или данните, които не са ни наистина нужни или използваме прекалено рядко) и т.н. Даде пример как няма нужда да измерваме температурата в стаята ни през 30 секунди, например. Какво ще се случи за толкова време? Помогна ми да взема решение за home automation-а, защото се чудих дали 2 минути са ок за измерване, но може дори и на повече.

 

“Testing Red Hat Enterprise Linux the Microsoft way” – Alexander Todorov от RedHat

Александър говори основно за pariwaise testing, installation testing и спомена, че за автоматизация на инсталациите използват Anaconda.

Разказва за спецификите на тестване на инсталатора на RedHat – симулация на iSCSI (с и без authentication) например, за това как един тест кейс може да продължи по 30 минути.

Говори за оптимизиране на test matrix (нещо за което трябва да прочета повече). Освен това трябва да си припомня и повече за pairwaise. За големи test suites и направен правилно може да даде впечатляващи резултати.

В общи линии разказа, че използва 3 tiers – първия е набор от тестове, който намира около 30% от всички логнато бъгове, втория набор е от всички тестове, които ползва (още около 30% от намерените бъгове са от тях) и 30% са от exploratory testing. Останалите 10% са дефекти (4 critical) – 1 firmware dependent, 1 corner case в s390x  (не може да се закачи правилно по NFS, hidden dependency и разлика в работата на IPv6 иIPv6) и третия в недостатъчно тестване (human error).

В извод pairwaise има доста силни страни така, че трябва да бъде използван от нас често и мъдро за да намалим броя на нашите test cases без да афектираме качеството.

 

Обедна почивка – време за networking, хапване, кафе и дойде време на:

 

“The future of computing” – Laurent Bugnion от Microsoft

Забавния Laurent Bugnion с интересния швейцарски акцент започна с историята за computing_а отзад-напред – със старите лентови карти, огромни комютри и т.н.

После мина на Blockchain:

  • Blockchain не е само валута;
  • Децентрализирано сигурно предаване на информация;
  • Информацията е най-ценния ни ресурс.

Следваща точка беше cloud computing (напомни ми на онзи лаф, че не качваш на cloud, а на компютъра на друг човек). Спомена Azure, OneDrive, Amazon Cloud Services и накрая – “Абе и Apple май имат някаква такава услуга, но …” и се засмя :D

Спомена за serverless computing (помните ли Силиконовата долина и идеята им за разпределено изчисляване (decentralized computing)?). (последните няколко знака заприличаха на някакъв извратен regular expression :D ).

Направи и малко демо с Cortana (като първия път фейлна :D) за времето, да му напомни нещо и накрая интересното беше “Като се прибера ми напомни да направя еди си кое”. Имаше и tell me a joke и хумора беше трагичен :) Следващата част на лекцията беше за AI/ML (Artificial Intelligence, Machine Learning). Едно нещо не ми хареса – каза, че ще направи serverless demo, но после каза – “Upload-ваме това на сървъра”. Това е тъпо и ще прочета малко за тяхната идея за serverless и ще видим каква е тяхната дефиниция.Та – направи един пример в Azure cognitive services с blob upload event (тови е event при upload на снимка в нашия случай) успя да прочете нещо надписано на ръка. Успя от две свои снимки с Emotion API да разпознае емоцията на лицето си с доста добра точност. Дойде ред на Augmented reality (пример беше Pokeymon Go) и Virtual Reality (напълно виртуална реалност, рендирана от някакво изчислително устройство). Спомена с и известна надсмешка за Google Cardboard glasses (които по дефиниция са супер евтини, мисля $2 и после почти директно ги сравни с VR на Acer) и HoloLens и mixed reality (смесена AR и VR – практически можем да взаимодействаме с реалния свят смесен с виртуална реалност).Показа и забавно демо с един космонавт над публиката. HoloLens заби само веднъж, а стрийминга беше ужасно бавен. Сигурен съм, че ползва 2.4 GHz мрежа. И пак Apple reference като спря stream-а – “Can you turn off your phones?” :D Показа едно тъпо демо с едни кубове и после дойде някакво абрусдно добро демо за планиране на индустриални структури упралвяемо с глас и жестове (добави кран/махни кран/покажи информация за този кран). Презентацията и кода можете да видите тук.

До момента най-забавна/приятна/интерактивна лекция.

 

В почивката имах възможност да се запозная с Алекс Тодоров, който е супер активен в нашата сфера и поддържа един от най-интересните блогове за QA в България – http://atodorov.org/ а след това и се запознах (най-накрая!) с Виктор Славчев – още един страхотен лектор и блогър. Нещата му можете да видите тук – http://mrslavchev.com/

 

“A Team Contributing Full-time to Open Source Projects – A Primer on Making It Happen in Your Company” – Iancho Dimitrov, Dimitar Ivanov – Musala Soft

 Двамата лектора изглеждат интересни и разказаха защо е ок да работят върху / разработват open-source проект.
До момента разказаха основно за МусалаСофт.  След това заговориха за smart home и споменаха OpenHab и SmartHome.Продължават да говорят основно за Мусала.

Разказаха как са убедили борда на директорите, че имат нужда от opensource проект по който да работят и в момента по него са включени 10+ програмистра (full-time) и един Senior Dev (part-time mentoring).

Описали са доста документация, доста unit тестове и са метнали тежките задачи. После е последвал static code analysis, работа по интеграцията с различни устройства и разбира се са вложили вътрешните си, вече утвърдени процеси в разработката.

Малко разпиляна ми дойде лекцията така, че на TL DR – пичове са решили да се занимават с open source, харесали са си smart home идеята, убедили са мениджмънта, че ще е яко ако имат такъв проект и с времето са набавили 10+ човека, които работят за проекта постоянно. И нещо важно – казаха, че по-неопитните хора, които първо са минали през този opensource проект са се интегрирали много по-бързо и по-качествено във фирмената инфраструктура работейки по комерсиалните проекти.

 

“Mastering scrum mastering” – Nikola Bogdanov от Fourth

Започва с това, че има куче и че е от Добрич. Оставам до края на лекцията! Учи за PhD и води университетски класове (не каза къде).

Започва със самото начало, защо SCRUM е важен, какво прави един scrum master и т.н. Разказа как в началото на agile stuff всичко е било self-organizing team и как е минало доста време докато се оформи нуждата на отделен човек, който да работи като scrum-master.

Scrum master as a teacher:

  • Boundaries;
  • Alignment;
  • Constraints;
  • Support;
  • Observations.

 

Scrum Master Evolution Model:

  • ScrumDude – part time, Schedules meetings, time keeping, three questions, Lists positives & negatives;
  • ScrumMom – Moderates meetings, protects the team, directly removes impediments, team interface, artificial harmony, bossy, cares about velocity and delivery dates;
  • True ScrumMaster – facilitates meetings, grows the teams long term, delegates & analyses, makes the team responsible and accountable, encourgages and motivates, mirror of the team, leads by example, an experimenter;
  • Agile Guru Lama Sensei – light for the team, sees & feels the matrix, holds the space, refills & inspires, just listens & reflects, flow & evolution, asks powerful questions, kokoro teacher.

 

“Automating Web security testing” – Yavor Papazov – CyresLab

Явор разказа с голямо въодушевление и страст за това, което прави. Разказа как не се прави вече:

Yesterday’s IT projects:

  • Waterfall methodology;
  • Testing comes after construction and before deployment;
  • Discrete releases;
  • A release of a project can be certified for security
    • e.g. common criteria

 

И как се прави сега:

Today’s IT projects:

  • We’re Agile now
    • We don’t do releases
  • Tendencies
    • DevOps
    • Continuous Integration;
    • Continuous Deployment
  • Cloud-first design
    • Elastic Load Balancing & Autoscaling
    • Systems that manage themselves

Обясни ни за това, че има два подхода към сигурността:

  • Options A: Give up security at release and work to improve it afterwards
    • Resilience instead of security
  • Option B: Ensure security early along the software production pipeline
    • Leads to automating security testing

Спомена и за Chaos Monkey.

 

Защо автоматизирането на security тестовете е трудно:

  • Lack of well-defines security requirements
    • “Make it secure” is not well-defined;
  • Most security requirements are non-functional
    • “Make it secure” is non-functional
  • Lack of well-defined security requirements
    • Check “Application security verification standard” by OWASP
    • CWEs
  • Most security requirements are non-functional
    • We can translate some requirements to functional

 

What other people use:

  • OWASP ZAP (Zed Attack Proxy) – had API
  • BDD-security )Confinuum Security)
  • Mittn (F-Secure)
  • Gauntlt

Demo time:

 

Това беше края на ден първи. Имах удоволствието накрая да се запозная лично с the Microsoft dude и с Явор и побъбрихме мъничко. Беше много приятно да видя, че извън сцената хората са си същите – без много взимане на сериозно, много приятелско и тополо отношение.

 

 

Stay tuned за ден втори :)

Мина EU Code Week Varna 2017

13/10/2017 / / 0 Comments

И ето, че мина Code Week Варна 2017.

Презентацията си я направих на 90% Петък вечерта стоейки до около 2:00., а сутринта отидохме два часа по-рано от старта на Code Week-а в Costa Coffee, изсмуках едно flat white (което съдържа три къси еспресота) за отрицателно време и пренаписах 80% от презентацията.

Качихме се в презентационната зала на хотел “Черно Море” и останах много доволен – имаше мек килим под нас (който е от съществено значение да се изчисти кънтенето в залата), страхотни столове, тюлени пердета, които не пропускат светлина за да може да се вижда какво презентирам на проектора.
Малко преди старта оставих малките изненадки, които Немечек любезно ми предоставиха (отварачки за бира, които са и поставки за такава, весели химикалчета с ръчички и тефтерчета със скрити в тях бонбонки (казващи се “Plan B – creativity boosters”)) и беше крайно време за първи контакт с хората (и тест на това дали всички ме чуват добре. Побърборихме си малко с всички (докато все още влизаха хора) и си личеше от тогава, че презентацията ще е приятна – средната възраст беше под 27, хората бяха разговорливи и не се притесняваха да комуникираме открито.

Презентацията започна в 10:10, Галин Желелязков, организатора на EU Code Week Varna, започна с всъпателни слова за Code Week, разказа с лекота за организацията и идеята на събитието и дойде моя ред като първи лектор.

Залата събира по думи на организацията 120 човека и беше почти пълна, което беше много приятна гледка (особено и за първа лекция). Говорихме на дълго и на широко за всякакви неща, хората се включваха от време на време, имаше и кикотене при някои от меметата, които бяха в презентацията.
Силно се надявам някой да се е вдъхновил и да е почел малко повече по темата.
На Александър Тодоров дължа извинение, че обърках къде работеше. Правилния отговор е Red Hat Enterprise.

И на IT бога Светлин Наков на който му обърках името.

Останалите лекции бяха на:

Страхотни лекции. Юлиан по навик е харизматичен и надъхващ, Преслав Михайлов с който се запознахме преди началото на събитието беше приятен и с лекота разказа нещата, които очевидно са му доста интересни, Жан говори със страстта на човек, който се кефи супер много на това, което прави, Галина Момчева отново демонстрира класа с нейните идеи, а накрая Aaron събра всички около себе си и демострира колко е интересно човек да се занимава с 3D Printing.

 

И малко линкове:
Линк към събитието във Фейсбук;

Медийна подкрепа на събитието имаше от moreto.net, БНР Варна, kmeta.bg, youthub.bg, Информационна агенция “Черно Море” и интервю с Галин Желязков. Искаше ми се информационните агенции и “информационните агенции” да имат малко въображение и да си пишат новините сами, а не да copy/paste директно от събитието.

Презентацията ми:


(Ако се чудите как се embed-ва Google Slides в WordPress (и не само) можете да прочетете тук)

Моите видеа:

Част първа:

Част втора:

Част трета:

 

 

Всички видеа можете да намерите тук:

 

И малко снимки :)