Мој омиљени уређивач текста је Геани. Веома је минималистички ОВДЈЕ који подржава огроман скуп језика – шкољка, пхп, питхон, Ц … итд. Има свој финиш, а истовремено је врло спретан. Недостаје јој још једна пријатна прилика, али тренутно ми је то више него довољно. Започео сам курс на мрежи Питхон програмирање на СофтУни – да освежим своје знање и надоградим га јер нисам адекватно надгледао шта се дешава са питхон-ом 3. Предавачи курса препоручују ПиЦхарм као ИДЕ за програмирање протона, али не свиђа ми се, наравно да користим Геани за вежбе.

Током предавања осећала сам се болно 2 недостаје

  1. питхон аутоматски довршава издисаје из документације функција и метода
  2. нема потврду за пеп8 стандард

Добра ствар је што је Геани довољно флексибилан за подешавање и може га лако надопунити недостајућим.. Нека да додајте питхон документацију у нашу ИДЕ:

  • ми повлачимо следећа скрипта негде у нашој ПАТХ на пример / уср / бин и не заборавите да то учините извршним
  • уредите датотеку ~ / .цонфиг / геани / филедефс / филетипес.питхон додавањем следећег ретка у одељку поставки контекст_преглед_цмд = пидоцв% с. Ако постоји само додајте име бинарног записа из претходног корака. Поново покрећемо Геани ако буде објављен.
  • Већ имамо контекст-радњу која ће вам добити информације о функцији. Аз си добавих shortcut за да ми е по удобно като не ми е ясно някоя функционалност. Овај приступ ми се јако допада јер ме нервира приступ нетбеан-а.

Засада је добро. Тада заиста желим да потврдим код који напишем – да ли пишем према општеприхваћеним стандардима или пишем неку ружноћу. У основи сам га поново нашао туториалче како се ствари дешавају али је помало застарјело – Геани има све уграђено у њу, само требате да инсталирате пеп8 пакет. У Дебиан апт-гет инсталл пеп8 делује у осталим дистросима сами морате сазнати како се догађа магија. У менију „Буилд“ друго дугме (барем за мене) је Линт након што га кликнете сазнаћете како сте створили ружни код 😀

Снимка екрана од 2016-01-11 20-42-21

Ово је општи оквир како да ваш Геани боље ради са Питхон-ом, а притом је и даље брз, без да ваш ЦПУ жели да повуче метак..

Сертификација у ипв6.хе.нет имати дневне тестове који се дају 1 додатни поен након проласка свих основних тестова. Они морају бити готови 100 такви тестови за максимални резултат 😐 . Сами тестови су потпуно тривијални

  • Трацероуте
  • ИОУ АААА
  • ИОУ ПТР
  • Пинг
  • Ко је

Најнепријатније је што сами тестови морају бити јединствени, тј. Не можете два пута користити један домен 🙂 Поред свега осталог, они помало сметају 🙄 – није изазов само шамарити 5 команде у цли-у и копирај / залијепи резултат на своју веб локацију.

Као лијен и администратор који воли да му олакшава живот, брзо сам се огребао елементарним кретеном који ради прљави посао за мене.

#!/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

Као што видите, скрипта је сулудо једноставна. Предавате домен и затим га потврдите да бисте видели постоји ли запис ИПв6 и ако јесте, вршите свакодневне тестове за њега. Најхладнији део – функција хр која штампа линију по целој ширини екрана хакерски хакери.

A shell script wants your job

Данас, док сам радио, видео сам да једна од машина лежи врло лоше. Улазим у то гледајући како се крон налеће на пакао многих зомби процеса (отприлике около 50-60). Није било начина да их све убијем киллалл па сам морао донети мало компетентније решење проблема – цртати елементарно branč скрипту за проналажење и убијање процеса. 50-ПИД-ове није лако написати руком :Д. Отресао сам се скрипте на минут и врло је једноставан, али свеједно заслужује пажњу 🙂

У његовој основи је транспортна трака

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

Овде добијамо листу са свим ПИД-овима процеса које морамо убити искључујући греп са ове листе. Сада када имамо списак, ствари постају једноставне, све се претвара у једно. Ево крајњег резултата

#!/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

Може бити “подешавање” као што се име узима као аргумент након имена скрипте и тако се назива бинарним извршним датотекама. Међутим, није тако добра пракса да имамо такве честе случајеве 😀 Али то нас никада не спречава да се заштитимо од било којег

Појачано од Земанта

Днес си играх да оптимизирам една бавна 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 в частта [мисклд] с декларацията 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 символаотговорът е не знам. Принципно мисля, че да, защото не е казано друго в документацията, но в документацията очевидно не се казват или показват много неща 😀

Појачано од Земанта

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

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

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

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