Skip to content

Author: Недко

Author, writer, cyclist and a passionate QA engineer that love to share his knowledge with everyone.

Да видим какво може новия Gutenberg

Както писах скоро излезе WordPress 5.0 с новия редактор Gutenberg.

Галерията пак и отново не е с някакъв slideshow + lightbox или нещо от типа, а пак просто плющи thumbnails на снимките и това за това. Не ме кефи, защото трябва да се инсталира и още един плъгин и стават 5 милиона неща…

Има и разни hading-и

и т.н. pull quote

Както и build-in embed на доста външни услуги.

WordPress 5 иде. Като лавина. От лава. И гръмотевици.

Днес трбява да излезе WordPress 5.0,за който говорят толкова време, че вече ми втръсна. Основното подобрение спрямо 4.9.8 (latest към момента) е, че ще използва нов редактор – Gutenberg (на името на човека измислил печатарската преса Johannes Gensfleisch zur Laden zum Gutenberg). Няма други значими функционални ъпдейти, няма и оправени някакви security проблеми.

На кратко за Gutenberg – опитах да го подкарам, но при мен гръмна с редица JS грешки, предполагам е от мен проблема. От екипа обещават това да е еволюция в редакторите, но аз единственото което искам от него е:

  • Проекта да не е 2000+ файла;
  • Респективно да не се зарежда за 1.5+ секунди в браузъра;
  • Да не генерира gibberish HTML при paste на форматиран текст.

Туй то. I’m a simple man – I see fast and reliable wysiwyg editor, I use it.

Та след масовия ъпдейт, който започва от днес имайки предвид, че 30% от интернет е задвижван от WordPress, което е около 76.5 милиона сайта (като ежедневно се създават над 50 000 сайта на WordPress) очаквам при ъпдейта а се строшат немалко инсталации.

Защо?

Ако имате чиста инталация на WordPress със стара версия и ъпдейтнете до 5.0 предполагам (даже съм сигурен), че всичко ще мине гладко и за секунди.
Но ако имате от онези пребити website builders или някоя тема, която носи със себе си 96 плъгина, 500 файла и е кракната очаквайте няколко безсънни нощи.

 

Няколко препоръки от мен:

  1. Задължително днес си направете бекъп на файловете и базата (не разчитайте на хостинга, те може да имат стари бекъпи);
  2. Огледайте се кои плъгини използвате и кои не. Не забравяйте, че дори и да не е активен плъгина може да бъде exploit-нат (при някакво security issue). Проверете плъгините, които използвате дали са съвместими с 5.0 (това от WordPress repo-то). Ако не са тествани не е задължително да се строшат, но шанса не е малък;
  3. Огледайте си правата на WordPress-а. Ако сте имали неприятности и сте набичили всичко с chmod -R 400 . вероятността нещо да се счупи не е малка;
  4. Помните ли първа точка с бекъпа?
  5. By default от 5.0 нататък редактора ни ще е Gutenberg. Ако сте любопитни го има в repo-то на WordPress и можете да го инсталирате с версия 4.x като плъгин. Можете да видите и малко ревю тук.
  6. Можете да използвате и стария редактор като го инсталирате като плъгин;
  7. Ако сте религиозни – недейте. Вярвайте на бекъпите, особено ако имате по-посещаем сайт от този, който четете.

 

Нека бекъпите бъдат с вас и дано Gutenberg да ви хареса.

Добре, че не станах системен администратор

Днес се самообявих за най-големия олигофрен, който познавам.

Мигрирам marvin от един VPS provider към друг и изведнъж достъпа ми до стария VPS по SSH спря. И не мога да се логна нито от офиса нито от нас. И писах едни мейли, една кореспонденция, едно чудо.
И успявам да се закача за console applet-а , но не мога да прехвърля файловете си през SSH.

ДВЕ СЕДМИЦИ. Две седмици ми отне да се сетя, че имам fail2ban, който явно не съм конфигурирал или съм конфигурирал по някакъв тъп начин и съм си blacklist-нал сам достъпа до двете IP-та.

За тези на които хипоталамуса им изтръпва при този проблем – четете долните редове. Ако сте сисадмин и знаете отговора – затворете сайта и никога повече не влизайте. All the shame…

Та – играта ви е в:

/etc/hosts.allow

/etc/hosts.deny

Влизате с нужните права в /etc/hosts.deny и вижте вашето IP дали не е там. Ако е – можете да го коментирате и да го добавите в /etc/hosts.allow.

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

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

Първо каране за месеца

Мда, мина прекалено много време и след няколко жалки опита да стана сутрин и да карам днес се реших. Навлякох най-дебелата си екипировка сякаш навън е -5 и карах в морската градина (до Аладжа Манастир исках да отида, но спускането щеше да ме вкочани). Карах, гледах изгрева, пак карах и така…
Нямам търпение да сменят времето (което ще стане този уикенд събота срещу неделя) и да имам още малко време да карам сутрините.

 

In other news:

Свръхчовекът и интервюто му с мен

Както писах преди време Жоро от Свръхчовекът с Георги Ненов ме покани да поговорим малко за Дунав Ултра, мотивация и за още няколко интересни неща.
Подкаста излезе и можете да го чуете тук:

 

Благодаря на Жоро за страхотното интервю!

10.10.2018

Днес Златина ме изненада с нещо ново, което вече въртя за незнамсикойпът.

In other news:

  • Случи се! След 7 години и един сериозен security breach (май най-големия на Google изобщо?) ще спрат Google Plus. Повече информация можете да прочетете в техния блог;
  • Нещо, което трябваше да се случи преди много повече време, но и това е добро начало – от сега нататък само default android apps ще имат достъп до SMS и call log-а;
  • Microsoft пуснаха fix-нат (уж) October Update, който на някои инсталации триел файлове, сини екрани, драми в три действия и т.н.  В офиса го бях качил и нямах проблеми.

Гостувах на Свръхчовекът

Вчера се видяхме с Жоро, който ми помогна супер много за подготовката ми за Дунав Ултра и записахме един епизод за Свръхчовекът с Георги Ненов.

Колкото и пъти да се видя с него все се удивлявам на мега енергията, която кипи от него.

Поговорихме си надълго и на широко за Дунав Ултра, за спорта, за мотивацията и за трудностите, за добротата и за Dimmu Borgir.

Очаквайте подкаста на 23.10.2018 г.

05.10.2018

Болен съм. Кашлям като спиритуалното ми животно (магаре) и съм grumpy as fuck през повечето време.

И тъй де, да не хленча и тук. Търсим кола със Златина и респективно от около месец четем и двамата като ненормални. Няма български автомобилен форум в който да не съм регистриран и да не съм влязал в абсурдни детайли. Цялото това нещо в началото неше забавно, но след седмица-две се превърна в нещо, което вече искам да приключи.
Живота без кола се оказа pain in the ass като цяло – таксита, автобуси, маршрутки обилно обвити в мизерия и всякакви неблаговонни аромати.

 

In other news:

  • От 2019 г. максималния осигурителен праг ще бъде повишен от 2600 до 3000 лв. което е огромен скок. От това ще последват повече данъци за нас като служители и за нашите работодатели и то на немалка база;
  • Уилиям Дафо ще играе Винсент ван Гог. Трябва да призная, че избора на главен актьор много ме учуди, но трейлъра е поразителен. И все пак се надявам да си заслужава и да е поне толкова емоционално зареден както в онзи епизод на Dr. Who;
  • Вчера в офиса обсъждахме какъв хард би бил полезен за обща употреба. И първо се метнахме на червената серия на WD, после на Re (която е безбожно скъпа) и накрая стигнахме до общия извод, че ако някой от нас реши да си купува диск за обща употреба (например втори за storage) най-добрия вариант би бил Blue серията – т.е. най-евтината от всички. Това е така, защото всеки от останалите серии са специализирани за нещо и не добри в друго. Та ако се чудите какъв диск да си вземете единственото важно е да е нов и ако искате да спестите някой лев – да не е специализиран.
    Btw на NAS-а вкъщи понеже е една кочина от много и различни дискове, които съм събирал с времето redundancy-то му е компроментирано още преди да съм го пуснал заради многото стари и различни дискове. Не правете моята грешка.