По традиция и тази година ще има 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

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