Tag: Live blogging

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

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

ISTA 2017 live blogging day 1

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 за ден втори :)