Category: Лекции

ISTA 2018 live blogging, day 2

Добро утро.
Винаги е приятно да влезеш в зала с десетки хора, които говорят за 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.

ISTA 2018 live blogging, day 1

По традиция и тази година ще има live blogging на ISTAcon.

 

Денят започна с opening speech и проблеми с микрофоните и озвучението. Добре, че беше първия лектор да разсее малко малките спънки и да поговори с харизмата на човек, който познава нещата в детайли:

 

Keynote Session: The Internet of Things is dead, long live the internet – Brandon Satrom, Co-Founder and CEO of Tangibl

 

Говорейки за харизма един от най-приятните за слушане лектори тази година определено отива към Брандън. В неговия keynote той ни разказа за разбиранията си за Internet of Things, където неизменно ми светна за LoraWAN и Варненското и Великотърновското общество, което разпространява идеята.

Според Брандън Internet of Things не може да бъде стабилна прекалено много време поради много фактори и предлага да го разглеждаме като … Интернет.
Разказа ни за Mesh networking, нещо, което е супер интересно и при интерес ще разпиша малко повече за него. Много грубо казано това е вътрешна мрежа, която не е expose-ната за външния свят и не зависи от интернет свързаността. Например ако имате датчик за наводнение и помпа за отводняване не е нужно и двете да са свързани с интернет, да разчитат на него и да пращат данните/респективно да се контролират от сървис, който е някъде навън като може комуникацията да стане вътрешно, датчика да подаде сигнал към помпата, която да си свърши работата. Разбира се няма да е приятно да не знаем какво става в дома ни, но не е ли по-добре automation-а да си свърши работата отколкото докато къщата се пълни с вода и настава микро катаклизъм те да ping-ват сървиса да видят дали не е Online? :)

В почивката се видяхме с Виктор Славчев и Александър Тодоров. Винаги е приятно да се видим и поговорим макар, че липсваше бирата. Ще видим довечера дали ще наваксаме :)

Developer’s survival guide: bug fixing for smart devices – Alexander Kostadinov, Senior Software Engineer at Musala Soft

Александър Костадинов говори и миналата ISTA за проекта, който разработва.

Към момента лекцията му беше основно репорт за това какво са постигнали. Разказа за (QA) процесите по техния проект, които звучат доста стандартни към момента. Интересно е, че са си организирали бъговете по категории (пак не е нещо революционно, но е интересно) и се показват интересни неща.

Явно момчетта имат афинитет към категоризиране на неща. Показаха и reaction Average reaction time по категории (find cause, re-test, apply fix re-deploy). При интерес ще пиша повече по темата с категоризациите, че е хубави за всички да видят по-голямата картинка от време на време.

 

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

 

Как да преживеем като тестващи хора (не само QA, а и всеки, които тества каквото и да е в коя да е фаза на проекта) в свят на бъгове и неработещи (от всякакъв тип) неща:

  • Използвайте всяка възможност за тестване – при писане на код, когато имате други задачи, които не са свързани с тестване, когато се присетите за някой евентуален flow докато deploy-вате кода си. Това ще ви позволи да погледнете проекта през друг ъгъл, който понякога изтърваме докато се опитваме да покрием други критерии. Например при deploy на testing environment съм се сещал да правя експерименти с липсващи библиотеки или такива със стари версии. Беше грозно :)
  • Преди deploy (без значение дали е на dev/QA/pre-prod или prod среда) винаги проверявайте какво по приекта е ъпдейтнато. Например ако има нови dependencies/нова верия на API/framework е важно да се види changelog-а и да се изтества, защото е добро място за задаждането на много сконфузни ситуации от типа на – “Ама то работи при мен…”.

 

Bug avoidance

  • Опитайте се да покриете всички възможни ексепшъни  за които се сещате (превода ми е покъртителен. В оригинал е “Try to make sure you handle all possible exception”)
  • Логвайте, но внимателно. Там където няма нужда от 120 редови stack traces по-добре не ги логвайте. Знам, знам – винаги е по-добре да има колкото се може повече информация, но хората, които дебъгват могат много лесно в цялата вълна от логове да изтърват критичните моменти. Обратната ситуация с логването на почти никакви данни също е лоша практика.
  • Логвайте stack traces само при реална грешка. Това може да е да кажем липса на достъп до някой сървис. Няма смисъл да логвате stack traces за нещо като активирана валидация, например (би било жалко, нали? :D )
  • Не игнорирайте и логиката при висока конкурентност, особено при асинхронни операции. При нужда винаги приотизирайте
  • Без значение от code change-а, винаги правете full regression. Малък bugfix може да породи още 10
    • Тук аз трябва да добавя 1-2 забележки. Физически не е много оправдано да се прави full regression при най-малкия code change, но тук unit testing-а е наш най-добър приятел. Viva la automation!
  • Нека QA да тества по време на development фазата. Тук много зависи от организацията на компанията и процесите, но винаги е добре някой да види парче от вашата работа и да даде идеи и насоки за които не сме се сетили;
  • По възможност нека целия екип да е ангажиран с тестването в development фазата. Не говорим за това да дърпаме PM-а за ушите да гледа полуработещи неща (или функционалности без дизайн), но е страхотно да се обсъжда (дори на идейно ниво) текущата ни работа с целия екип. Така могат да бъдат отстранени проблеми още в зародиша им.

 

Bug investigation

  • Рестаритрането на машината почти никога не оправя проблемите;
  • Направете си предифинирани сетъпи за тестване. Ако тествате десктоп приложение например, което трябва да работи в предварително конфигурирана среда винаги е добре да имате една виртуална машина/контейнер, който да ви е фундамента в тестването. Така времето ви за реакция ще се намали драстично (представете си след всяка преинсталация на приложението да чистите/модифицирате регистри, да триете файлове, да конфигурирате разни сървиси, етц);
  • При тестване, респективно логване на бъгове е важно да описвате и версиите с които reproduce-вате. Иначе изобщо не е изключено да стане една километрична кореспонденция за да може след няколко изгубени човекочаса да стане ясно, че някой тества със стара версия на някоя билиотека/ОС/framework). Been there – done that.
  • Не забравяйте да гледате логовете. Те са ваш приятел, дори и да са много (за референция прочетете няколко точки по-нагоре)
  • Приемете го – unhandled exception може да се логне като бъг, дори и да се вижда само по логовете. Handle-вайте си ексепшъните за да няма драма
  • Наистина се постарайте преди да кажете, че бъга е “not reproducible”.

 

How we survived?

  • Постоянна комнуникация между всички членове на екипа (ако не правите daily meetings – те са добро начало);
  • Let’s face it – ако нямате добър domain knowledge колкото и добър програмист да сте ще е трудно не само на вас, но и на екипа в който работите;
  • Обикновено при development фазата програмистите не са много сговорчиви за bug fixing, но това е нужно. Опитайте да ги редувате – хем за разведряване на обстановката, хем да не ви се наложи да фиксвате десетки бъгове след development фазата.

 

Пф. Изписах си писането. Ако на някой му е интересно или има въпроси нека не се стеснява и да пита.

 

 

CI/CD in cloud independent environment – Toshko Todorov

Тошко започна силно с няколко мемета. Темата му за Continuous Integration / Continuous Delivery е интересна.

Разказа малко философски за контейнерите (в лицето на Докер), за CI и CD

Като цяло презентацията му беше много обща и наистина нямам какво друго интересно да ви предам.

Мина QA: Challenge Accepted 4.0

За по-малко от 7 дни успях да сбъдна две мечти, които бях запланувал за тази година – да изкарам двата бревета от 200+300 км за един уикенд и да говоря на QA: Challenge Accepted (над 500 човека).

Ако четете това значи лекцията е минала и съм оцелял.

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

Видеото ще е на разположение след няколко седмици, а статията ми за конфигурацията на Grafana & InfluxDB + теста на jMeter  ще дойде скоро.

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

Повече инфо + разказ за вчера и днес – по-натам, че нито аз ще издържа, нито черния ми дроб към този момент :D

Ваш,
Недко.

 

Ще бъда лектор на QA: Challenge Accepted 4.0

Снощи получих мейл от организаторите, че моята тема е одобрена и на 21.04.2018 г. ще бъда един от лекторите на QA: Challenge Accepted 4.0. Това ще е най-голямото събитие на което ще посетя като лектор (според организаторите ще има над 400 човека в един единствен трак) и по спомен май първото с по-advanced тема и то пред колеги. Темата ми е “Performing Performance testing – why, who, how – step by step” В рамките на половин час ще демонстрирам вдигането на influxDB, Grafana (вероятно с docker, че няма да стигне времето за всичко), ще конфигурирам jMeter и ще пуснем няколко performance теста, които после ще анализираме и ще покажем красотата (която натурално липсва на jMeter) на графиките, които могат да бъдат направени четими и красиви не само за QA/dev хората, но и за клиенти/PM/PO/etc.   Тук ще сложа презентацията, а запис ще има предоставен от QA Challenge Accepted.

QA: Challenge Accepted 4.0

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

 

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

 

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

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

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

  • Не водих лекции в Социалната Чайна. Преди няколко месеца излязоха открито и казаха, че парите им не стигат. Тогава се свързах с тях и говорихме да водя лекции в тяхната зала, а приходите (всеки плаща колкото реши) да отиват в Чайната. По същото време смених работата и реших да забавя нещата за да мога да се концентрирам върху нея;
  • Почти не снимах. За поредна година;
  • Почти не танцувах;
    • Нямам нито едно представление за годината.
  • Не говорих на 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 часа за това казват и че е по-възможен);
  • Дунав Ултра – много се надявам да успея да участвам и да финиширам в контролното време;
  • Да изкарам първия си мартон.

 

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

My year in sport 2017

Тази година започна силно и приключи като издут наполовина балон. Последните почти 4 месеца не съм карал/тичал и това ще е една от целите ми за следващата година.

2017 година в цифри:

  • Колоездене:
    • Средно колоездачно разстояние на тренировка – 32 км;
    • Най-дълго каране – 219 км (Велико Търново – Казанлък – вр. Шипка – Велико Търново);
    • 84 пъти съм подобрявал личните си рекорди;
    • Обща дистанция – 3780 км (не съм карал последните 4 месеца от годината);
    • Общо 197 часа прекарани в колоездачни тренировки;
    • 135 карания;
    • 2 бревета – първия го изкарах за под 10 часа за 200 км, а следващия ден на 300 км. се провалих и минах едва половината. Оказа се, че все пак не съм чак толкова fit колкото си мислих и 500 км. за два дни са прекалено;
    • Карах 3-4 пъти MTB преди и по време на двата дуатлона. Със сигурност се чувствам доста по-уверен от първия си дуатлон, който беше екшън и половина, но все пак не мисля, че това е нещото за мен.
  • Бягане:
    • 68.4 км бягане от които 23 км. в две карания на два дуатлона;
    • Направих най-бързите си 5 км до сега за 26 минути за което писах.

 

Тук можете да видите и видеото, което ми генерира Strava.

Цели за следващата година:

  • Да участвам и изкарам в контролното време Дунав Ултра
    • Малко повече информация – бях одобрен за участие в Дунав Ултра 2017, но започнах нова работа и везните наклониха към работата. Следващата година силно се надявам да успея да участвам.
  • Тази година исках да направя 5000 км. на колелото от които направих под 4к. Ако бях продължил с каранията може би щях да ги направя. През 2018 г. ще гоня поне 5000 км. (което е 14 км средно на ден) като ще гледам да се концентрирам върху бреветите (200 км +300 км + (евентуално) 600км );
  • Ще изкарам първия си маратон (42.195 км.). Да, знам, дебел съм. И не – няма да се оставя така. Целта ми ще е да изкарам един пълен маратон в контролното време като вероятно ще се пусна и на един half-marathon да видя как се движа;
  • Имам една крайно извратена мечта и тя е да се пусна на триатлон, но не съм сигурен, че ще успея да се подготвя за една година.

Мина Zara Code Week 2017

Мина втория ми за годината Code Week този път в Стара Загора само няколко седмици след Code Week Varna 2017.

Бях поканен от Венко Добрев, който е от ония суперактивни хора, които искат да правят света около себе си по-добър и не мрънкат, а действат.  И понеже е и скромен ще опиша аз с какво се занимава – беше управител на Beehive за година и половина, два пъти е организирал Code Week Варна (като веднъж бях сред лекторите там), два пъти в Стара Загора, два Startup Weekend-а, бил е един от организаторите на TEDxStaraZagora, помага на брутално якия coworking space ZaraLab (Венко, ако четеш това прати малко снимки да покажем на хората колко яко е местенцето). Освен това започна нова образователна инициатива за мотивация на ученици и отделно младежи в неравностойно положение – “Аз и моят успех”. Опита се да направи нещата по-добри като работеше в община Стара Загора като младши специалист в отдел спорт, туризъм и младежки дейности и беше част от екипа писал кандидатурата за Европейски град на спорта 2017, която градът спечели. Сега работи като експерт в Агенция за регионално икономическо развитие – Стара Загора по два международни проекта с колегите – единият за иновации в МСП в селските райони, а другият за зелени обществени поръчки. Сигурно има и други неща, които пропускам.

Та – той беше една от причините да пропътуваме 300 км. Другата бяха останалите лектори, които бяха епични копелета, а на трето, но изобщо не на последно място – хората, които щяхме да срещнем там.

Тръгнахме в Събота, 21 Октомври от Варна и за съжление изтървахме откриването и голяма част от лекцията на Петър ПетровAndroid between Java and Kotlin“. Това, което видях беше интересно и сигурно много практично за Android devs. Лекцията беше много chill, както и повечето от лекциите от двата дни. За Пешо хубаво или нищо! Дори вече не помня от къде се познаваме, но като го представям на някого обикновено споменавам, че първо се е научил да свири на гъдулка (ей, винаги съм си мислил, че е гайда, деба!) и после да програмира.

Последва може би най-епичната лекция от събитието с най-епичния лектор – Oрлин Димитров, който тръгна да говори за “Свързаност на елементите на роботизираните системи“, но след десетата минута и зададени 5 въпроса смени темата и изкара на freestyle почти два часа пълни с хардуер и софтуер и хумор, а в края залата беше залята от мощната вълна ентусиазъм, която Орлин хвърля винаги, когато говори пред хора. Той е и един от виновниците да се запаля по микроконтролите последните седмици. (Орлине – ти ще отговаряш пред Златина защо съм си дал половината заплата за контролери!)

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

ИТ-ПОП-ИДОЛА Михаил Дучев известен сред своите приятели, колеги и врагове като Дучев, още по-известен като грамар-нацито на Интернета, бъг хънтъра на себеподобни, човека, който чупи всичко по пътя си и т.н. и т.н. Та той говори за Xamarin като се посмяхме, показа някои интересни неща и беше достойно (Дучев за 3 минути намери eastern-egg-а, браво :D) закриване на първия ден на Zara Code Week 2017.
Останахме да спим в Митака (Митак №2 всъщност), а преди това се събрахме на бърза и културна вечеря на местна кръчма (на която забравих името). Та там салатите бяха два типа – от 500 и от 1000 гр. Със Златина успяхме да смачкаме една 500 грамова с малко зор.
След като се правихме на културни за около 12 минути някой започна с първия виц и така до полунощ минахме от тъпи вицове, които всеки знае до най-дълбоките дебри на черния хумор. Беше абсолютно епично и още повече да говориш с такива хора, които имат толкова много неща да споделят (и хумора е само малка част от тях).

Прибрахме се и легнахме. На следващия ден аз бях с откриващата лекция.

Станахме в 7 и към 8:00 се замъкнахме в бизнес сградата в която щеше да се проведе събитието. Поръчахме по едно кафе и направих финални щрихи (тоест си донаписах презентацията :D) на презентацията (баси тъпото повторение), хората започнаха да се нижат един по един и в 10:30-10:40 излязох да говоря аз.

Минах набързо през основните неща, които казвам на лекциите си и се насочих към темата за сигурност. Разказах в известни детайли как да направим анализ на някакъв уеб ресурс, който в случая беше моя блог (не ми се искаше пак да чупим общинско/държавно on the fly), разказах за DVWA и накрая пуснах един dictionary attack към блога ми. Разказах малко за Google Dorks, a накрая имаше и малко performance testing с jMeter, за който не остана много време, че вече бях направил почти два часа.

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

След мен излезе Димитър Костов за да говори за Mobile scaffolding. Лекцията беше супер полезна и интересна, разказа доста неща и най-накрая научих какво е scaffolding. Също така беше и единствения лектор, който излезе и започна да говори за това, което прави от самото начало така, че да бъде разбран добре и от хора, които нямат никакъв опит в бранша. Получи се добра лекция.
Решихме след него да си ходим със Злати, но се оказа, че Митака и Тошко са към Варна и останахме за предпоследната лекция на Тодор Янков – “Интро в JavaScript”. Презентацията му беше web based с интеграции и най-вече – code snippet editor директно в нея.

Разказа ни за JS, react и направи един съвсем лек проект (взимаше JSON данни от weather provider и ги показваше на екрана). Имаше и супер много въпроси, дискусии и показа завидни познания по linux/zsh/vim.
Тръгнахме като ми беше терсене, че няма да чуем последната лекция на нашия домакин – Димитър Стефанов, който е backend developer в Big Mustache Game говори за “Grimm side of programming”. Самия той се занимава от безброй много години със C# .NET и MSSQL и разказа за C#, релационните база данни и концепцията клиент/сървър (това ми беше преразказано от Венко като каза, че лекцията е била доста добра).

 

Снимки – скоро.

ISTA 2017

Най-накрая ще присъствам на ISTA 2017 на 16.12 – 17.12.2017 г. в Sofia Event Center! Последния път бях на ISTA 2013 и от тогава насам трима работодатели са обещавали, че ще отида и така и не отидох. Явно изкарах късмет със сегашните, защото попитах и получих одобрение за няколко часа.

Те така – ISTA е една от много малкото QA конференции, които се провеждат в България. Тази година цифрите са още по-впечатляващи – 3 последнователни трака, повече от 30 презентатора, над 750 присъстващи и билет само за 123 евра. Ще има бая интересни неща и ще опитам да направя live blogging както направих за WordCamp Varna 2017 пък да видим какво ще стане.

Ако ще участвате и вие пишете да се видим там.

 

P.S. Писах на отганизаторите за един малък бъг на сайта им, да видим дали няма да ме напсуват :)

Честит празник на народните Будители

Помня първия ми учебен ден. Беше преди 22-23 години. Бях рус, с черно костюмче и държах един голям букет увит в целофан в ръце, майка, татко и брат ми бяха около мен. Всички се вълнуваха супер много, а в двора на училището цареше невероятен глъч. Помня огромния коридор, огромния чин и немалката раница, която до последно татко държеше в ръце да не ми тежи. Влезе началната ни учителка и започна да ни показва смисъла на света около нас, научи ни да четем, да смятаме, а в нас ме научиха на също много неща.

Времето минаваше и аз останах много тих, срамежлив и бях най-малкия по размери от всички в класа ми. Дойде края на осми клас и се преместих в ново училище. Там от първия ден помня Директора, учителката по информатика, тази по математика, по БЕЛ и т.н. Те всички за мен бяха Будители. Събуждаха в мен любопитството, желанието за знания и нуждата от такова, а аз попивах колкото можех.
След като завърших желанието за знание не спря. Започнах висшето си образование и помня добре първия път когато един от преподавателите ми каза “Недко – искаш ли да водиш часове тук в Университета?”

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

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

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

 

Нека всеки от нас буди колкото може повече хора около себе си, нека всеки дава. Защото колкото повече даваме в тоя наш занаят толкова повече ще вземем. Ще взимаме усмивки, нови колеги, нови знания и не на последно място – огромни дози вдъхновение.

Честит празник на народните будители.