Любимият ми текстови редактор е Geany. Той е много минималистично IDE което поддържа огромен набор от езици – shell, php, python, C … etc. Има си автоматично довършване и същевременно е адски пъргаво. Липсват му някоя и друга приятна възможност но и към момента за мен е повече от напълно достатъчен. Започнах да online курса Python Programming на SoftUni – да си освежа познанията и да ги надградя тъй като не съм следил адекватно какво се случва с python 3. Лекторите от курса препоръчват PyCharm като IDE за pyton програмиране, но на мен далеч не ми е по вкуса, естествено си използвам Geany за упражненията.

По време на лекциите болезнено усетих 2 липси

  1. python autocomplete-а издиша от към документация на функции и методи
  2. няма валидация за pep8 стандарта

Хубавото е че Geany е достатъчно гъвкав от към конфигурация и може лесно да бъде допълван от към липсващи такива. Нека да добавим python документация към нашето IDE:

  • дърпаме си следният скрипт някъде в нашият PATH например /usr/bin като не забравяме да го направим изпълним
  • редактираме файла ~/.config/geany/filedefs/filetypes.python като в частта settings добавяме следният ред context_action_cmd=pydocw %s. Ако съществува само добавяме името на бинарката от предишната стъпка. Рестартираме Geany ако е пуснат.
  • Вече имаме context-action който ще ви извади информация за функцията. Аз си добавих shortcut за  да ми е по удобно като не ми е ясно някоя функционалност. Лич мен този подход много ми допада защото много ме дразни netbeans подхода.

До тук добре. След това много ми се прииска да имам валидация на кода който пиша – дали го пиша според общо приетите стандарти или пиша някакви грозотии. В общи линии намерих отново туториалче как се случват нещата но то е малко остаряло – Geany си има всичко вградено в себе си само трябва да му се инсталира pep8 пакета. В Debian apt-get install pep8 върши работа в останалите дистрота сами трябва да откриете как се случва магията. В менюто Build вторият бутон (поне при мен) е Lint след кликването му ще откриете колко грозен код сте сътворили 😀

Screenshot from 2016-01-11 20-42-21

Това е общи линии как да накарате вашият Geany да работи по добре с Python и същевременно да продължи да бъде бърз без да кара процесора ви да иска да си тегли куршума.

Сертифицирането в ipv6.he.net имат дневни тестове които дават по 1 допълнителна точка след като си минал всички основни тестове. Трябва да се направят 100 такива теста за максимален резултат 😐 . Тестовете сами по себе си са напълно тривиални

  • Traceroute
  • DIG AAAA
  • DIG PTR
  • Ping
  • Whois

Най неприятното е че самите тестове трябва да са уникални т.е не може да използваш един домейн двапъти 🙂 Освен всичко друго са и малко досадни 🙄 – никакво предизвикателство просто плющиш 5 команди в cli-то и copy/paste на резултата в техният сайт.

Като мързелив и администратор който обича да си улеснява живота надрасках на бързо едно елементарно bash-че което да върши черната работа вместо мен

#!/bin/bash

hr() {
  local start=$'\e(0' end=$'\e(B' line='qqqqqqqqqqqqqqqq'
  local cols=${COLUMNS:-$(tput cols)}
  while ((${#line} < cols)); do line+="$line"; done
  printf '%s%s%s\n' "$start" "${line:0:cols}" "$end"
}

if [ -z $1 ]
then
  echo "Append domain afert the script name!!!"
  exit
fi

IP=$(dig $1 AAAA +short)

if [ -z ${IP} ]
then
  echo "$1 dont have valid IPv6 record"
else
  reset
  traceroute6 $1
  hr
  dig $1 AAAA
  hr
  dig -x ${IP}
  hr
  ping6 -c3 ${IP}
  hr 
  whois ${IP}
fi

Както се вижда скрипта е безумно елементарен. Подаваш домейн след което го валидира дали има IPv6 запис и ако има извършва дневните тестове за него. Най готината част – функцията hr която принтира линия по цялата ширина на екрана е взета от bash-hackers.

A shell script wants your job

Днес докато работех видях че една от машините лагна много жестоко. Влизам в нея гледам един cron наблъскал адски много зомби процеси (грубо около 50-60). Нямаше как да ги убия всички с killall затова се наложи да направя малко по грамотно решение на проблема – да драсна едно елементарно bash скриптче което да намери и убие процесите. 50-тина PID-а не се пишат лесно на ръка :D. Скрипта го надрасках за минута и е свръх елементарен но все пак заслужава внимание 🙂

В основата му седи конвейера

ps ax | grep -v grep | grep process_name | awk '{print $1}')

Тука получаваме лист с всички PID-ове на процеса който трябва да килнем като изключваме grep от този списък. Вече като имаме списъка нещата стават лесни всичко се завърта в един for. Ето го и крайния резултат

#!/bin/bash

PR=$(ps ax | grep -v grep | grep process_name | awk '{print $1}')

for PID in $PR
do
echo "$PID will be killed"
kill -9 $PID
done

Може да се „тунингова“ като името се взима като аргумент след името на скрипта и по този начин се вика като изпълнимо binary. Обаче не е много добра практика да има много такива чести случаи 😀 Но никога не пречи да сме предпазени от всякакви шитни

Enhanced by Zemanta

Днес си играх да оптимизирам една бавна SQL заявка от вида

SELECT * FROM 'table' WHERE `field` LIKE '%word%'

Къде е проблемният момент тука – последната част ‘%word%’ и в още по-голяма конкретност знака % преди думата, за която правим. Wildcard символът % ,преди която и да е стойност, директно ни превръща заявката директно в бавна, защото по този начин заявката ни спира да ползва индекси на полето. Решения както винаги има, но не винаги са ясни 😆 Общо взето MySQL си имат решение на тоя проблем с fulltext search индексиране на полето. Как става смяната на полето има много написано в документацията, но набързо ще опиша как се променя горната заявка, защото ще стигнем и до една малка драма накрая. Следка като приложим fulltext на полето горе, заявката трябва да се промени във вида:

SELECT * FROM `table` WHERE MATCH (field) AGAINST ('word')

Така структурата е очевидна и няма нужда от излишна дискусия. Горната заявка ще влезе в сила, ако думата, за която правите заявка е поне 4 символа, по подразбиране е това стойността, ако искате да я модифицирате трябва да укажете стойността, която желаете в my.cnf в частта  [mysqld] с декларацията ft_min_word_len=3 или 2, 1 не е добър избор очевидно 😉  . След като смените стойността и рестартирате mysql server-a трябва да направите repair на таблиците си, за да може новото индексиране да влезе в сила. До тук всичко ясно: правя промените, рестартирам, ребилдвам индексите и правя заявката и ми връща 0 реда 😀 Проверявам с

SHOW VARIABLES

Виждам че стойностите, който съм задал са влезли в сила, ребилдвам пак индексите – същия резултат. 🙄 Неприятно, много неприятно. От тук нататък започна едно голямо ругаене и ровене за ключа за бараката 😀 Който се оказа доста, доста интересен. Като цяло, като започнах да чета документацията за не знам кой път и стигнах до един интересен пасаж

 Such a technique works best with large collections (in fact, it was carefully tuned this way). For very small tables, word distribution does not adequately reflect their semantic value, and this model may sometimes produce bizarre results. For example, although the word “MySQL” is present in every row of the articles table shown earlier, a search for the word produces no results

ГРЕДА 😳  Дам табличката ми беше малка – все пак беше тестова. Наших заявката в една голяма таблица с над 2 000 000 реда и там нещата заспаха. Добре вече е ясен проблемът. За да стане ясно решението, ще спомена накратко, че full text search поддържа 3 разширени режима BOOLEAN , EXPRESSIONS и NATURAL LANGUAGE като последния работи по подразбиране. За различните режими може да проверите документацията, аз ще обясня с 2-3 думи за BOOLEAN понеже в него е разковничето. Той поддържа логически оператори от типа AND, OR , NOT и прочие и може да се правят разни магии с търсените фрази, да има една, да няма друга и прочие. Поддържа и символа *, който е еквивалент на wildcard символа % 😉 Той е полезен, когато търсената дума е под дължината на ft_min_word_len или за малки таблички ;). Поне при мен на таблица с около 100 реда върши идеална работа. Остана само да видим и завършената заявка:

SELECT * FROM `table` WHERE MATCH (field)
AGAINST ('*word*' IN BOOLEAN MODE)

Тука вече идва момент дали ни работи индексирането с wildcard символа – отговорът е не знам. Принципно мисля, че да, защото не е казано друго в документацията, но в документацията очевидно не се казват или показват много неща 😀

Enhanced by Zemanta

За единия проект които водя в gitweb ме дразнеше, че няма оцветяване на кода в дървото. Лесен начин как да оцветите синтаксиса в tree частта на gitweb е като инсталирате пакета  highlight и добавите следния ред в /etc/gitweb.conf или където ви се намира конфигурационния файл на gitweb

$feature{‘highlight’}{‘default’} = [1];

За Debian пакета го има в пакетната система за другите дистрибуции не съм проверявал.

ps Има и алтернативен вариант като се правят промени по файловете на gitweb ама ми се стори безсмислено като има простичък вариант 🙂