Ха, uptime robot ми светна, че сайта е бил долу през вечерта със супер информативното съобщение – “There has been a critical error on this website”. Любопитно, но се оказа, че го е счупил един google plugin, който не възнамерявам да връщам обратно.
Набързо за white screen of death и стъпките за дебъгване:
Проверка на това колко свободно място на диска и в RAM паметта имаме:
marvinator@marvin $ free -m
total used free shared buff/cache available
Mem: 1967 1752 66 64 368 214
marvinator@marvin $ free -m
total used free shared buff/cache available
Mem: 1967 738 990 55 450 1229
Така е по-добре, от 66MB към 738MB. Това не е перманентно решение и ще трябва да си оптимизирам малко сървисите, но за сега – толкова.
2. Това не помогна да се реши проблема така, че отиваме в логовете на nginx (които взимаме от /etc/nginx/conf.d/{default}.conf) ей така (ако файла се казва default.com):
Правим един tail и с него гледаме какво се случва във файла след като refresh-нем страницата и ето го зайчето:
marvinator@marvin / $ tail -f /var/log/nginx/default.error.log
2024/09/10 07:58:14 [error] 2704424#2704424: *2661604 Failed to open stream: No such file or directory in /xxx/xxx/wp-content/plugins/google-site-kit/includes/loader.php on line 62;
Вероятно е минал някакъв ъпдейт, който е потрошил плъгина и оттам WordPress е изпаднал в паника. Решението ми беше да преместя или изтрия директорията от plugins и така да позволя на WordPress да си се зареди правилно.
Takeaways:
Трябва да повече оптимизирам сървисите, които имам и да спра тези, които не използвам
Трябва да спра (вече е направено) автоматичните ъпдейти на плъгините. Бях пуснал само тях преди време (без ъпдейт на WordPress core), но беше въпрос на време нещо да се наака
Безплатния tier на UptimeRobot за веченезнамкойпът си върши работата чудесно.
Последните години не бях добра компания както в блога така и понякога 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 кг. така, че съм далеч от тази категория) и има ок колело.
Както виждате ще е challenge и то дългосрочен, което ме прави нетърпелив и може би и щастлив.
Заедно с това ще последва и неизбежното сваляне на килограмите, защото сега положението е стил дамаджана малко. Влизайки в режим обикновено бързо ми се случват нещата, но да видим как ще е този път.
Техническата тема, която винаги ми е била слабост ще я разпиша в друг пост, че този започна да става в стил 2000 думи, но основното ми е ъпгрейда, който направих преди няколко месеца от винтидж шосейния велосипед, който си има нов собственик (още ми е тъжно, че го продадох, велико колело беше) на един страхотен шосеен велосипед – Triban RC520 – full Shimano 105, дискови хидравлични спирачки и страхотна геометрия.
Крайната цел на всичко това е един здрав татко и съпруг, който да дава всичко, което има за семейството си, а не един постоянно изморен чичко.
П.С. Ако някой има някакъв интерес към нещо конкетно може да пише в коментарите – дали ще е трасето, подготовката, хранене, бих споделил всичко, което знам.
tl;dr – Понеже блога си остана едно от много малкото места в които мога да синтезирам това, което ми е интересно и знам смятам да направя редица фокусирани върху сигурността постове. Повече информация можете да прочетете в края на статията.
Списък на планираните теми, които са готови или са в процес са както следва:
Студенти, стаж и работа – накрато информацията, която аз нямах като влизах в бранша, описание на стълбицата, какво трябва и какво не е нужно да умеем в началото, no deep shit. Progress – 100%;
Security fundamentals – стегнато описани основните концепции, no deep shit. Progress – 10%;
Основни атаки – без много blabla, списък с десетте най-разпространени атаки, какво представляват и примери как да ги приложим, инструменти, примери;
Практическо ръководство – ще заорем в DVWA и примери, решения и най-вече – защо нещо работи и защо не (това ще е публикувано по време на QA: Challenge Accepted като разширена тема от лекцията ми). Кодовото име ще е “From lizard to wizard in security testing”;
Как да строшим WordPress – имам вече лекция по темата в WordPress.TV, но тук ще я развием още (и ще пропуснем частта с костюма, ъ-кането и ще е по-кратка и съдържателна. Имам някаква идея да покажа това на моя блог, но ще видим дали ще има видео по темата.
Правене на презентация под стрес и с лимитирано време – как се справих аз, какъв ми беше плана и 3 основни правила, които следвах за да говоря пред 800 човека без да направя прекалено големи издънки. Progress – 15%.
Добро утро.
Винаги е приятно да влезеш в зала с десетки хора, които говорят за 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.
По традиция и тази година ще има 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
Като цяло презентацията му беше много обща и наистина нямам какво друго интересно да ви предам.
Както писах преди време Жоро от Свръхчовекът с Георги Ненов ме покани да поговорим малко за Дунав Ултра, мотивация и за още няколко интересни неща.
Подкаста излезе и можете да го чуете тук:
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 или по-висока. Другото можете да направите с подобен синтаксис:
Излязоха данните от годишната акнета на StackOverflow за 2018 година. Винаги тази анкета е служила за много добра индикация накъде сме откъм технологии, навици, заплащане и т.н.;
Професор Стивън Хоукинг си замина на 76 г. оставяйки в много от нас нуждата да знаем, да погледнем нагоре (или в нас) и да се борим. Почина 50 години по-късно отколкото лекарите му бяха казали, че ще живее с ALS;
На 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 библиотечка или каквото се сетите;
Винаги съм се кефил много на ентусиастите, а на 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. Повече информация можете да прочетете тук;
Най-тъжното нещо, което съм чел тази година е едно несъмсигуренколкоточно изследване финансирано от изобщо неподкупните и политически независими 24часа. Няма да пиша нищо за него, защото брадата ми е още мокра от сълзите, които текоха като реки докато го четох първия път;
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 , защото е тъпо. Но не мога да не се сдържа да кажа, че това е един от най-известните съвременни учени, които ги е грижа и са толкова популярни извън специалистите в неговата област.
Книгите, които издаде (или участваше в издава) заслужават да бъдат изчетени и аз със сигурност ги мятам скоро:
“ЗА ЩАСТИЕ САМО НА ПЛАНЕТАТА ЗЕМЯ – Видът homo sapiens sapiens се върна на библейските си нива на разум считано от рано тази сутрин.
Това се случи, след като цивилизацията загуби един от онези свои представители, който въпреки невъзможността да се преметне през лост впечатляваше всички с физическото си състояние половин век повече, отколкото бяха прогнозите.
Резкият спад в умственото ниво на вида, измислил неща като “София: Ден и нощ” и същевременно “Черни дупки, бебета вселени и други есета” надали ще доведе до особени катаклизми и Вселената ще продължи да си вселенува.”
АМ ГОРЕ – Всевишният изпадна в паника, след като професор Стивън Хоукинг спря да съществува рано сутринта вчера.
“Само той знаеше горе-долу как работи всичко това, което аз създадох в един от своите пиянски периоди” – завайка се Господ.
Той нерядко е ползвал знанията на Хоукинг, за да поддържа Вселената в сравнителен порядък и в някаква степен логична.
“Сега, ако нещо се бастиса, кого да питам? Някой професор от Библиотекарския ли? Не е хубаво това, вече ме е яд, че тая работа със задгробния живот я лансирах само като шега за глуповатите” – кахърен бе Създателят на Северното сияние, гравитацията, проказата и инстаграм профила на Николета Лозанова.
Единственият вариант с поправяне на Вселената сега е тя да бъде застрахована, но Бог смята, че застрахователите ще го изпържат и винаги ще казват, че щетите са по негова вина поради небрежност.
Не почивай в мир, а бъди сред звездите, намери отговорите и се усмихвай в някоя галактия, so far away.
