Category: Future articles

Радикални промени

26/11/2021 / / 1 Comment

Последните години не бях добра компания както в блога така и понякога f2f. Реших да ви разкажа доскоро пазена дълбоко в мен тайна, защото е важно за мен.

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

И с депресията ми се измениха и интересите и част от мен някак заспа. Последния път когато говорих пред хора (мисля беше на QA: Challenge Accepted) вече ми се струва супер далечен, а желание за това, поне за сега, нямам. Нямам и желание да танцувам и да карам колелото, нещо, което исках с цялото си сърце и душа.

Ако запомните едно нещо от този пост то е – ако се чувствате тъжни постоянно, ако усещате, че сте в дупка, ако не виждате много смисъл в това, което правите в офиса и вкъщи – говорете с някого. 2-3-5 срещи понякога са напълно достатъчни да се адресира проблема и да работите за разрешаването му. Хората имаме склонност към запазване на доста усложнени модели на света около нас в главите си и понякога някои малки и дори смешни неща като например … например някой съсед да ви изгледа накриво може да ви счупи настроението за целия ден. И много често причината не е това, а нещо по-дълбоко, по-неочевидно и ако разберете какво е то можете много, много по-лесно да го обработите, храносмелите и изхвърлите от мислите си.

Дължа много на Златина, която е с мен и ме търпи когато не съм особено страхотна компания и ми помага с всичко с което може. За това и винаги ще я обичам.

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

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

Е, радикалната ми промяна ще се състои в няколко стъпки и искам да съм прозрачен към вас:

  • Спорт ( + план и статуса му)
  • Редовно блогване със споделяне на мотивация и резултати
  • Подкаст поне 2 пъти месечно

И понеже човека е същество, което обича да разбира света наоколо и се е научил да прави планове за бъдещето така и аз реших да си поставя дългосрочна цел, която да е да … wait for it … wait for it …

да участвам в най-стария и все още активен бревет в света – Париж – Брест – Париж, който е 1400 км в категория 90 часа


А за да се случи това трябва да изпълня следното изискване – да имам за един сезон (Октомври до Септември) изкарани следните бревети – 200 км, 300 км 400 км и 600 км (единствения двудневен бревет) като това ще ми донесе титлата супер рендоньор, която е пожизнена и няколко медалчета за завършените километри. Едва след като изкарам дистанциите във времето определено от организаторите мога да участвам в предварително записване за PBP и вече ако има свободни места може да ме приемат. Таксата общо е около 200 евро и включва храна по checkpoint–ите, сервизни автомобили и застраховка.

Сега се чудите сигурно (ако не сте чели преди блога) дали е възможно това и ще ви кажа, че освен възможно това може да е и едно наистина страхотно изживяване. През моите около 18000 км на колело стигнах до моята истина, която е, че карането е 50% дух и воля и 50% подготовка. Това не значи, че сега ще мога да се метна на 600 км и да ги изкарам безпроблемно, но всичките тези километри могат да бъдат изкарани от всеки човек, който е поне малко fit (аз към момента тежа 108 кг. така, че съм далеч от тази категория) и има ок колело.

Към момента плана за бреветите ми е следния:

СтарусИме на
бревета		ДатаДължинаДенивелацияКонтролно
време
Успешно изкаранВанра – Алекси Николов11.12.2021203210713:30
Резово12.03 / 19.03430 км.3001 м.27 ч.
Исперих03.06 / 4.06402 км.3220 м.27 ч.
Тракийски26.03 / 2.04208 км.1466 м.13:30 ч.
Загоре15.01204 км.1228 м.13:30 ч.
Странджа05.02 / 12.02228 км.2553 м.13:30 ч.
Варна 30009.04 / 16.04207 км.3574 м.20 ч..
Успешно изкаранВарна 20010.04 / 17.04218 км.1524 м.13:30 ч.
Сакар19.02 / 26.02301 км.1943 м.20 ч.
Шипка11.06300 км.3682 м.20 ч.
Шипка12.06200 км.2553 м.201
Исперих25 – 06.06608 км.2553 м.40 ч.
Данните са взети от официалния Audax randonneurs Bulgaria

Както виждате ще е challenge и то дългосрочен, което ме прави нетърпелив и може би и щастлив.

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

Техническата тема, която винаги ми е била слабост ще я разпиша в друг пост, че този започна да става в стил 2000 думи, но основното ми е ъпгрейда, който направих преди няколко месеца от винтидж шосейния велосипед, който си има нов собственик (още ми е тъжно, че го продадох, велико колело беше) на един страхотен шосеен велосипед – Triban RC520 – full Shimano 105, дискови хидравлични спирачки и страхотна геометрия.


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


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

QA: Challenge Accepted 6.0 English podcast

12/09/2020 / / 0 Comments

A (not) so short English version of my talk “How (not) to talk at conferences” at QA: Challenge Accepted 6.0.

It’s my first episode of the series. On the next episodes of the series I’ll cover:

  • Soft skills
  • Hard skills
  • Practical presentation examples
  • Fighting a stage fright
  • memes!

Questions

If you have questions you can ask them on Discord or at https://sli.do/NedTalk

Нови теми в блога

19/03/2019 / / 0 Comments

tl;dr – Понеже блога си остана едно от много малкото места в които мога да синтезирам това, което ми е интересно и знам смятам да направя редица фокусирани върху сигурността постове. Повече информация можете да прочетете в края на статията.

Списък на планираните теми, които са готови или са в процес са както следва:

  1. Студенти, стаж и работа – накрато информацията, която аз нямах като влизах в бранша, описание на стълбицата, какво трябва и какво не е нужно да умеем в началото, no deep shit. Progress – 100%;
  2. Security fundamentals – стегнато описани основните концепции, no deep shit. Progress – 10%;
  3. Основни атаки – без много blabla, списък с десетте най-разпространени атаки, какво представляват и примери как да ги приложим, инструменти, примери;
  4. Практическо ръководство – ще заорем в DVWA и примери, решения и най-вече – защо нещо работи и защо не (това ще е публикувано по време на QA: Challenge Accepted като разширена тема от лекцията ми). Кодовото име ще е “From lizard to wizard in security testing”;
  5. Как да строшим WordPress – имам вече лекция по темата в WordPress.TV, но тук ще я развием още (и ще пропуснем частта с костюма, ъ-кането и ще е по-кратка и съдържателна. Имам някаква идея да покажа това на моя блог, но ще видим дали ще има видео по темата.
  6. Правене на презентация под стрес и с лимитирано време – как се справих аз, какъв ми беше плана и 3 основни правила, които следвах за да говоря пред 800 човека без да направя прекалено големи издънки. Progress – 15%.
  7. Отговор на задачата ми за QA: Challenge Accepted 5.0.

Continue reading

ISTA 2018 live blogging, day 2

16/11/2018 / / 0 Comments

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

15/11/2018 / / 0 Comments

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

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

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

24/10/2018 / / 0 Comments

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

 

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

Излезе видеото на лекцията ми в QA: Challenge Accepted!

29/06/2018 / / 0 Comments

Излезе видеото от лекцията ми на QA: Challenge Accepted 2018.

 

Освен, че гласът ми трепери като на ученичка мисля, че не се справих толкова лошо.

Линк към презентацията можете да намерите тук.

В канала са и останалите видеа и lightning talks също.

03.2018

29/03/2018 / / 0 Comments

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

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 не работи така, че който иска да ми спами блога сега е момента.

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

15/03/2018 / / 0 Comments

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

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

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

 

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

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

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

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

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

 

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

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

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

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

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

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

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

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

11/01/2018 / / 6 Comments

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

Хардуерът

Развойна платка: 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 и на Златина че ме изтърпя докато в нас беше катаклизъм от кабели, платки и документация.