Kedvenc szövegszerkesztőm Geany. Nagyon minimalista IDE amely támogatja a hatalmas nyelvek halmazát – héj, php, piton, C … stb.. Automatikus befejezéssel rendelkezik, ugyanakkor nagyon mozgékony. Hiányzik más kellemes lehetőség, ám jelenleg több mint elegendő számomra. Online tanfolyamot indítottam Python programozás a SoftUni – hogy frissítsem ismereteimet és frissítsem, mert nem figyeltem meg megfelelően, hogy mi történik a python-nal 3. A kurzus előadói ajánlják PyCharm IDE-ként a pyton programozásához, de nekem nem tetszik, természetesen Geanyt használom a gyakorlatokra.

Az előadások során fájdalmasan éreztem magam 2 hiányzik

  1. A python automatikus kiegészítése kilép a funkciók és módszerek dokumentációjából
  2. nincs érvényesítés a pep8 szabvány

A jó dolog az, hogy a Geany rugalmasan konfigurálható, és hiánytalanokkal könnyen kiegészíthető.. Néha add Python dokumentációt az IDE-hez:

  • húzunk a következő szkript például valahol a PATH-ban / usr / bin, és nem felejtsük el, hogy végrehajthatóvá tesszük
  • szerkessze a ~ / .config / geany / filedefs / filetypes.python fájlt a következő sor hozzáadásával a beállítások szakaszban context_action_cmd = pydocw% s. Ha csak az előző lépésből adjuk hozzá a bináris fájl nevét. Indítsuk újra a Geanyt, ha elengedik.
  • Már van egy kontextusművelet, amely információkat kap a funkcióról. Аз си добавих shortcut за да ми е по удобно като не ми е ясно някоя функционалност. Nagyon tetszik ez a megközelítés, mert nagyon bosszant a netbeans megközelítés.

Eddig jó. Akkor nagyon szeretnék érvényesíteni az általam írt kódot – függetlenül attól, hogy az általánosan elfogadott szabványok szerint írom-e, vagy némi rondatot írok-e. Alapvetően újra megtaláltam útmutatók hogy történnek a dolgok, de egy kicsit elavult – Geany mindent beépített, csak telepítenie kell a pep8 csomagot. A Debian alkalmazásban az apt-get install pep8 működik a többi disztróban is, amit magának kell megtudnia, hogyan történik a varázslat. Az Építés menüben a második gomb (legalább nekem) a Lint, rákattintás után megtudhatja, milyen csúnya kódot hozott létre 😀

Képernyőkép a 2016-01-11 20-42-21

Az alábbiakban bemutatjuk egy általános vázlatot arról, hogyan lehet jobbá tenni a Geany-t a Python-nal, miközben továbbra is gyors, anélkül, hogy a processzor akarsz húzni a golyót.

Tanúsítás ipv6.he.net napi teszteket kell végezniük 1 egy plusz pont az összes alapvető teszt elvégzése után. Meg kell csinálni 100 ilyen tesztek a maximális pontszámért 😐 . Maguk a tesztek teljesen triviálisak

  • traceroute
  • TE AAAA
  • TE PTR
  • fütyülés
  • Kicsoda

A leg kellemetlenebb dolog az, hogy maguknak a teszteknek egyedinek kell lenniük, azaz nem használhat kétszer egy domain-t everything Minden más mellett kissé idegesítő 🙄 – nincs kihívás, csak csapkod 5 parancsok a cli-ben, és az eredmény másolása / beillesztése a webhelyen.

Lusta és adminisztrátorként, aki szeretné megkönnyíteni az életét, gyorsan megkarcoltam egy elemi bash-ot, amely értem piszkos munkát végez.

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

Mint láthatja, a szkript őrületten egyszerű. Ön beküld egy domain-t, majd ellenőrzi azt, hogy van-e IPv6-rekord, és ha igen, akkor naponta végezzen rá teszteket. A legmenőbb rész – funkció hr amelyből egy sort nyomtat ki a képernyő teljes szélességén, ki kell venni bash-hackerek.

A shell script wants your job

Ma, míg dolgoztam, láttam, hogy az egyik gép nagyon rosszul fekszik. Megyek bele, amikor egy cron sok zombi folyamat pokolába ütköz (nagyjából körül 50-60). Semmilyen módon nem tudtam megölni őket Öld meg mind tehát kicsit kompetens módon kellett megoldást találnom a problémára – elemi rajzoláshoz Bash egy szkript a folyamatok megkeresésére és megölésére. 50-A PID-ket nem könnyű kézzel írni :D. Egy percig megkapartam a forgatókönyvet, és ez nagyon egyszerű, de még mindig érdemel figyelmet 🙂

Mélyén a szállítószalag található

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

Itt kapunk egy lapot az összes folyamat PID-jéről, amelyet meg kell ölnünk, ha a grep-et kizárjuk ebből a listából. Most, hogy megvan a listája, a dolgok egyszerűvé válnak, minden egyre fordul. Itt van a végeredmény

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

Lehet “hangolás” mivel a nevet argumentumnak veszik a szkript neve után, és ezért végrehajtható binárisnak nevezik. Ugyanakkor nem túl jó gyakorlat, hogy ilyen gyakori esetekben legyenek

Javította 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 és 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 символаотговорът е не знам. Принципно мисля, че да, защото не е казано друго в документацията, но в документацията очевидно не се казват или показват много неща 😀

Javította Zemanta

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

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

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

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