Skip to content

Category: Future articles

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

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

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

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

 

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

03.2018

Този месец се учудвам колко малко съм писал.

Personal update – в офиса ми дадоха освен QA задачи по новия проект и да вдигна един VPS като staging server с nginx, mysql, проекта е писан на Laravel. Деплоя мина добре, проектите са up and running и като има задачки на сървърно ниво ги поемам аз, което ме кара да се чувствам много добре. И това основно заради marvin, който неведнъж съм искал да запаля. Our relationship is complicated, както казват :)

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

 

  • След Meltdown и Spectre дойде ред на amdflaws. Това са колекция от сериозни уязвимости според сайта. След един бърз и некомпетентен поглед от моя страна май не са като Meltdown/Spectre, а Линус Торвалдс тегли една майна на авторите. Няма да ви развалям удовоствието от четенето. Линус си е епичен както обикновено :)
  • Branch prediction attacks на много ниско ниво откриха в семейството процесори на Intel (само те са били тествани). Прочетете статията, дава малко светлина върху една интересна техника за branch predictions;
  • Semantic Versioning е проект, който описва по прост начин идеята за означението на версиите (versioning) като например какво значи версия 3.2.17. За хората с опит това е ясно, но за по-новите в бранша е ценен ресурс;
  • Камерата на Google Pixel използва AI-то, което правило снимките по-яки или поне така твърдят. В общи линии използват image segmentation, което разделя снимката на сегменти и ги сглобява с техен си алгоритъм. Така според тях качеството на снимките се подобрява значително;
  • Новината на годината в digital signed certificates сектора е, че Let’s Encrypt пуснаха поддръжка на wildcard certificates на цената на техните нормални сертификати или точно 0 лв! За целта трябва да добавите TXT domain record и да използвате техния API endpoint. Имайте предвид, че трябва да използвате certbot 0.22.0 или по-висока. Другото можете да направите с подобен синтаксис:
./certbot-auto --server https://acme-v02.api.letsencrypt.org/directory -d *.nedko.info --manual --preferred-challenges dns-01 certonly
  • Излязоха данните от годишната акнета на StackOverflow за 2018 година. Винаги тази анкета е служила за много добра индикация накъде сме откъм технологии, навици, заплащане и т.н.;
  • Професор Стивън Хоукинг си замина на 76 г. оставяйки в много от нас нуждата да знаем, да погледнем нагоре (или в нас) и да се борим. Почина 50 години по-късно отколкото лекарите му бяха казали, че ще живее с ALS;
  • YouTube имат намерението да борят fake news с линк към Wikipedia под видеата. Много се кефя на идеята, но ако човек гледа видеа за рептили е малко вероятно да седне и да изчете 5-6 страници статии и научни обосновки да кажем. Ще видим, дано помогне;
  • На Pi Day излезе моята любима джажда Raspberry Pi  3 Model B+ (последния да затвори вратата). Новия модел ще има 1.4 ghz quad-core Cortex A-53 процесор, 802.11.ac и Bluetooth 4.2, гигабитов нет (over usb 2.0) и подобрено оглаждане. Цената остава $35;
  • Фейсбук ми напомни, че преди 7 години им писах един благодарствен мейл, който още им виси на сайта. Бях техен клиент от около 2007 до 2016;
  • Едно леко извратено видео как елементарните неща, които можем да правим с десетки библиотеки и драйвери навремето на асемблер са се пишели на ръка. Това не е урок как да пишете на Асемблер, а по-скоро да си даваме по-често сметка колко ненужни ресурси заемаме с някой елементарен npm пакет, js библиотечка или каквото се сетите;
  • И как можем да подкараме Kali Linux на Windows 10 – native! Изисква много малко подготовка и работи добре;
  • Google изгуби продъжилия над 8 години съдебен спорт с Oracle относно и трябва да платят около 8.8 милиадра долара. Така, че внимавайте с лицензите ;)
  • Винаги съм се кефил много на ентусиастите, а на Paulo Constantino съм особен фен откакто разбрах, че е направил 8 битов процесор ей така just-for-fun. Схваща ми се ларинкса само като видя колко сложно изглежда на външен вид;
  • А ако някой има нужда да деплойне Laravel server някъде може да ползва tutorial-а на DigitalOcean, който на мен ми свърши страОтна работа;
  • Из българския интернет (блогосфера звучи тъпо) Божо говори за две наболели теми тия дни – това, че ГДБОП НЕ ни следят чатовете и повече информация за защита на личното ни пространство;
  • Програмист сте и си пускате локална среда, която в hosts файла задавате да бъде neshtosi.dev или neshtosi.foo. Отваряте го през Chrome и/или Firefox и БАМ – не можете, защото сертификата ви не е валиден? Какъв сертификат, бе? И не можете да продължите, защото имате HSTS? WTF? Споко – проблема не е във вас. От извесно време насам Chrome и Firefox force-ват gTLD-тата .dev и .foo към https с hsts. Повече информация можете да прочетете тук;
  • GitHub преживя най-голямата DDOS атака някога. Историята е интересна и препоръчвам да я прочетете;
  • И свързано донякъде с горния ред – да не забравите да си ъпдейтнете memcache-а;
  • Един модел за git branching, който е кратък и извънредно полезен;
  • Най-тъжното нещо, което съм чел тази година е едно несъмсигуренколкоточно изследване финансирано от изобщо неподкупните и политически независими 24часа. Няма да пиша нищо за него, защото брадата ми е още мокра от сълзите, които текоха като реки докато го четох първия път;
  • От серията “Научи xx за хх минути”, този път JS от Jeremy Thomas;
  • Ся, нещо важно – пускат Unity C# под reference-only license;
  • ngxtop е един много полезен проект, който ви показва в конзолата real-time метрики за натоварването на nginx. Писан е на Python и се инсталира елементарно през pip:
    pip install ngxtop

    Можете разбира се да намерите и WEB модул, който прави това, но официалния е Luameter и струва 40 евро.

 

P.S. Ако се чудите каква връзка има комикса със статията – няма. Но ми е любим откакто го открих :D

 

P.P.S. Генерирането на Akismet api keys не работи така, че който иска да ми спами блога сега е момента.

Замина си Стивън Хоукинг

Както вече разбрахте, днес IQ-то на света падна рязко. Всички се правим, че знаем колко голям е бил, но лично аз не мога да разкажа повече от 1% от това, което той е направил. И все пак е бил badass. Защо? Освен, че е гениален Хоукинг притежава още няколко неща, които прекалено малко хора имат. Едно от тях е, че през 60-те години, когато го диагностицират с ALS му казват, че ще живее още няколко години. Почина 50+ години по-късно вкопчил се в масивния клон на любопитството и нуждата да разгадае колкото се може повече загадки докато е жив. И успява. А теориите върху които е работил са:

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

Книгите, които издаде (или участваше в издава) заслужават да бъдат изчетени и аз със сигурност ги мятам скоро:

 

И последно, обещавам, искам да цитирам големия Самуил Петканов:

IQ-то на човечеството падна наполовина

ЗА ЩАСТИЕ САМО НА ПЛАНЕТАТА ЗЕМЯ – Видът homo sapiens sapiens се върна на библейските си нива на разум считано от рано тази сутрин.

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

Резкият спад в умственото ниво на вида, измислил неща като “София: Ден и нощ” и същевременно “Черни дупки, бебета вселени и други есета” надали ще доведе до особени катаклизми и Вселената ще продължи да си вселенува.”

 

Господ в паника: Само Хоукинг знаеше как работи цялото това Нещо

АМ ГОРЕ – Всевишният изпадна в паника, след като професор Стивън Хоукинг спря да съществува рано сутринта вчера.

“Само той знаеше горе-долу как работи всичко това, което аз създадох в един от своите пиянски периоди” – завайка се Господ.

Той нерядко е ползвал знанията на Хоукинг, за да поддържа Вселената в сравнителен порядък и в някаква степен логична.

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

Единственият вариант с поправяне на Вселената сега е тя да бъде застрахована, но Бог смята, че застрахователите ще го изпържат и винаги ще казват, че щетите са по негова вина поради небрежност.

 
 
 
Не почивай в мир, а бъди сред звездите, намери отговорите и се усмихвай в някоя галактия, so far away.
 
 
 
P.S. Хокинг е известен и с това, че е забавен и много ироничен (основно със себе си).

Датчик за фини прахови частици – как, защо и няколко идеи

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

Хардуерът

Развойна платка: ESP8266
Датчик за твърди частици: SDS011
Температурен датчик (+атмосферно налягане и влажност): BME280

 

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

Софтуерът

От софтуерна гледна точка нещата са елементарни. В сайта на Air Bulgaria са публикували готов firmware, който прави впечатляващи неща с контролера. Някои от тях:

  • WEB сървър, който сервира данните от датчиците в малка страничка достъпна от всеки потребител логнат в същата мрежа в която е устройството;
  • Вдига сам Wi-Fi spot към което потребителя може да се закачи за първоначална настройка. След това esp8266-то се закача за вашата мрежа и става клент както всяко друго Wi-Fi усторйство закачено към домашния ви рутер;
  • DHCP сървър за първоначална инициализация;
  • Може да изпраща данни към един или повече API endpoints;
  • Изпраща автоматично данните към http://luftdaten.info, а оттам https://airbg.info ги взимат и парсват до подходящ вид на тяхната карта;
  • Може да изпраща данните към InfluxDB;
  • Поддържа OTA updates (On-The-Air);
  • Поддържа доста сензори и дисплеи, които се настройват елементарно.

 

Моята идея

Към стандартната функционалност бих искам да добавя следните неща:

  • Физическо укрепление на системата (кутия, термошлаух, както писах по-горе и други малки неща);
  • Данните ще хвърлям и към InfluxDB, който (по идея на Стан) ще бъде в контейнер (хем да се науча да работя с тях, крайно време е!);
  • Grafana dashboard, защото всеки обича да му е красиво и функцоинално;
  • Независимо захранване. Понеже SDS011 не пести много ток, ще мисля вариант с измервания на една минута. Същото се отнася и за температурния датчик (и евентуална корекция за да синхронизирам двата). Енергонезависимостта му ще е осигурена с power bank (ако някой ден ми попадне соларно панелче, което да пълни power bank-а през деня ще стане епично).

 

Ето и как изгелжда работещия проект на с firmware-а на airbg.info:

 

Ако някой има интерес или въпроси може да пише под статията. Ако мога ще отговарям.

 

P.S. Най-важните неща за накрая. Нямаше да се хвана с този проект ако не бяха три основни фигури – Орлин, който на Zara Code Week миналата година ни показа, че електрониката изобщо не е толкова сложна колкото си мислим и че всеки в днешно време може да реализира IoT проект за отрицателно време, на Стан, че ми подари без причина ESP8266 и на Златина че ме изтърпя докато в нас беше катаклизъм от кабели, платки и документация.

Малки SQL трикове за WordPress

Когато не му се спи на човек ума му решава да прави неща, които в нормални условия не биха се случили (не и в този вид).
Ето и списък с няколко интересни SQL заявки, които можете да използвате докато работите с WordPress.

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

В този блог за 2017 година съм публикувал 155 поста. Чудя се това малко ли са или много, но колкото-толкова.
Интересно е друго – начина по който видях това. Оказа се съвсем лесно с SQL заявка, която изглежда по този начин:

select count(*) from wp_posts where YEAR(post_date) = 2017 and post_type = 'post' and post_status = 'publish'

Имайте предвид, че тази заявка показва само публикуваните постовете (не page или някакъв custom post type) за 2017 г.

Примерен резултат:

mysql> select count(*) from wp_posts where YEAR(post_date) = 2017 and post_type = 'post' and post_status = 'publish';
 +----------+
 | count(*) |
 +----------+
 | 155      |
 +----------+
 1 row in set (0.00 sec)

Ако искате да видите колко draft-а имате можете да изпълните тази заявка:

select count(*) from wp_posts where YEAR(post_date) = 2017 and post_type = 'post' and post_status = 'draft'

Примерен резултат:

mysql> select count(*) from wp_posts where YEAR(post_date) = 2017 and post_type = 'post' and post_status = 'draft';
 +----------+
 | count(*) |
 +----------+
 | 116      |
 +----------+
 1 row in set (0.00 sec)

 

И не – няма грешка. Имам цели 116 поста, които така и не съм публикувал, повечето от които са започнати и недовършени истории, няколко tutorial-а (още ме е яд, че не завърших този за HTTP/2) и няколко пътеписа.

Как да сменим siteurl и homeurl с един ред

Ако не сте чували за siteurl и homeurl няма страшно. Но ако се наложи да мигрирате сайта, да смените домейна или да добавите/премахнете HTTPS поддържка ще се наложи да поработите с тях.

UPDATE wp_options SET option_value = replace(option_value, 'http://www.nedko.info', 'https://www.nedko.info') WHERE option_name = 'home' OR option_name = 'siteurl'

След изпълнението на тази заявка при опит да достъпя сайта ще бъда пренасочван автоматично от non-HTTPS към HTTPS версията на блога. Можете да я използвате и при смян на домейн да кажем като смените втория линк на този, който желаете. Не е най-добрия пример, но е важно да схванете как работят siteurl и homeurl. Друга полза е ако ъпдейтвате сайта и имате да мигрирате да кажем https://nedko.info/v2 към https://nedko.info.

Работа с пароли

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

UPDATE wp_users SET user_pass = MD5( '123456' ) WHERE user_login = 'admin'

Тази заявка ще смени паролата на потребителя admin с 123456.

 

Ако ви се наложи да работите върху клиентска инсталация, но не искате да сменяте паролата на потребителя можете първо да запишете хеша ѝ със следната заявка:

select user_login,user_pass from wp_users

Примерен резутат:

mysql> select user_login,user_pass from wp_users;
+------------+---------------------------------------------------+
| user_login | user_pass                                         |                           |
+------------+---------------------------------------------------+
| admin      | $P$B5&50UGz0.kW3tq6jifraX.hT!РqZP.                |
+------------+---------------------------------------------------+
1 row in set (0.00 sec)

Сега запишете стойността на user_pass полето, изпълнете горната заявка, която ще смени паролата на 123456 и като сте готови просто изпълнете следната заявка за да върнете старата парола:

UPDATE wp_users SET user_pass = '$P$B5&50UGz0.kW3tq6jifraX.hT!РqZP.' WHERE user_login = 'admin'

 

Изтриване на всички спам коментари

Преди време ми се наложи да изтрия от един блог над 10 000 коментара. Tricky-то беше, че имаше и коментари от хора, не само спам. Решението е тривиално и се нарича Akismet. Безплатната версия върши страхотна работа, но имах проблем с привилегиите на DB потребителя и коментарите маркирани като спам не се триеха. За това използвах тази заявка за да ги изчистя (~10 000 коментара от които 90%-95% спам се изтриха за под 2 секунди):

DELETE FROM wp_comments WHERE comment_approved = 'spam'

Ако искате да изтриете и тези със статус awaiting moderation можете да ипозлвате следната заявка:

DELETE FROM wp_comments WHERE comment_approved = '0'

Как да видим всички неизползвани тагове

Ако искате да видите дали имате тагове, които никога не са използвани можете да изпълните тази заявка:

SELECT name,count from wp_terms wt INNER JOIN wp_term_taxonomy wtt ON wt.term_id=wtt.term_id WHERE wtt.taxonomy='post_tag' AND wtt.count=0

Примерен резултат:

mysql> SELECT name,count from wp_terms wt INNER JOIN wp_term_taxonomy wtt ON wt.term_id=wtt.term_id WHERE wtt.taxonomy='post_tag' AND wtt.count=0
 -> ;
+--------+-------+
| name | count |
+--------+-------+
| blabla | 0 |
+--------+-------+
1 row in set (0.00 sec)

Ако обаче искат да видите (спорд мен далеч по-практично) тагове, които са използвани 5 или по-малко пъти, сортирани по възходящ ред можете да изпълните следната заявка:

SELECT name,count from wp_terms wt INNER JOIN wp_term_taxonomy wtt ON wt.term_id=wtt.term_id WHERE wtt.taxonomy='post_tag' AND wtt.count<5 order by wtt.count DESC

Примерен резултат:

mysql> SELECT name,count from wp_terms wt INNER JOIN wp_term_taxonomy wtt ON wt.term_id=wtt.term_id WHERE wtt.taxonomy='post_tag' AND wtt.count<5 order by wtt.count
+--------------------------------------------------------+-------+
| name | count |
+--------------------------------------------------------+-------+
| blabla | 0 |
| humor | 1 |
| кино | 1 |
| котка | 1 |
| vulnerability | 1 |
+--------------------------------------------------------+-------+
5 rows in set (0.00 sec)

Извличане на всички мейли от коментарите на потребителите

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

select comment_author_email,comment_author_url,comment_date from wp_comments order by comment_date DESC

Тази заявка ще покаже мейла, сайта (ако има такъв попълнен) и датата на коментара. Това можете да го ползвате като ориентация.

Примерен резултат ще върне следните данни:

somemail@gmail.com | http://www.somedomain.com | 2017-11-01 17:18:19 |

Иначе можете да лимитирате само до списък с мейлите така:

select comment_author_email from wp_comments

 

P.S. For non-Bulgarian speakers:

  • What are you doing here?
  • If you think that the article will be useful I can translate it in English.

Равносметката 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 часа за това казват и че е по-възможен);
  • Дунав Ултра – много се надявам да успея да участвам и да финиширам в контролното време;
  • Да изкарам първия си мартон.

 

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

Мина EU Code Week Varna 2017

И ето, че мина 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.bgyouthub.bg, Информационна агенция “Черно Море” и интервю с Галин Желязков. Искаше ми се информационните агенции и “информационните агенции” да имат малко въображение и да си пишат новините сами, а не да copy/paste директно от събитието.

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


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

Моите видеа:

Част първа:

Част втора:

Част трета:

 

 

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

 

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