DN42 е един прекрасен проект който ви дава възможност да развивате вашите BGP умения без да чупите продуктова среда, без да ви се налага да имате скъпи устройства с които да си правите лаборатория да си правите симулации с GNS3. Същевременно да не е чисто лабораторна среда при която няма проблеми от реалният свят. Участвам с 1 node в проекта от около година. Един от проблемите в проекта е 1:1 с реалният святкогато някой ти обяви префикси които не трябва да обявява. Понеже съм мързелив и не ми се пише на ръка филтри все път, реших проблема с елементарен bash скрипт които ми генерира prefix-list с име dn42 и в него наливам валидните префикси.

#!/bin/bash</pre>
vtysh -c 'conf t' -c "no ip prefix-list dn42"; #drop old prefix list

while read pl
do
vtysh -c 'conf t' -c "$pl"; #insert prefix list row by row
done < <(curl -s https://ca.dn42.us/reg/filter.txt | grep -e ^[0-9] | awk '{ print "ip prefix-list dn42 seq " $1 " " $2 " " $3 " ge " $4 " le " $5}' | sed "s_/\([0-9]\+\) ge \1_/\1_g;s_/\([0-9]\+\) le \1_/\1_g");
vtysh -c 'wr' #write new prefix list

Списъка с валидните предикси се взема https://ca.dn42.us/reg/filter.txt от където и основният конвейр + малко модификации от моя страна за да може да се генерира префикс листа. Командите се изпълняват през vtysh.

我最喜欢的文本编辑器 Geany. 这是非常简约 HERE 支持一个巨大的语言范围 – 贝壳, PHP, 蟒蛇, C … 等等. 有自动完成,而地狱敏捷. 它缺乏偶尔愉快的可能,但目前对我来说是绰绰有余. 我开始在线课程 Python编程 наSoftUni – 刷新自己的知识和升级,因为我没有足够的后蟒蛇会发生什么 3. 该课程的讲师推荐 PyCharm 作为IDE编程pyton, 但对我来说远离我的喜好, 自然地使用Geany为演习.

在痛苦地感受到了讲座 2 短缺

  1. 蟒蛇自动完成和呼出从文档的函数和方法
  2. 没有验证的 PEP8标准

好消息是,Geany非常灵活,通过配置,可以很容易通过这种缺少补充. 让 加上Python文档 我们的IDE:

  • 拉你 下面的脚本 在某处我们的道路是的/ usr / bin中不要忘记使其可执行
  • 编辑文件〜/的.config / geany / filedefs / filetypes.python部分设置中添加以下行 context_action_cmd = pydocw%S. 如果仅来自前一步骤中加入binarkata的名称. 重新启动Geany如果运行.
  • 我们已经有上下文的动作,将删除有关功能的信息. 我已经向我首选添加一个快捷方式,看不到任何功能. 利奇我这个方法,因为我非常喜欢让我很烦NetBeans的方法.

到目前为止好. 然后,我真的很想有你写一个验证代码 – 我是否根据普遍接受的标准写或写任何丑陋. 总的来说,我又找到 tutorialče 事情是如何发生的,但它是一个有点过时 – Geany一切都已经内置到自己只需要安装它PEP8包. 在Debian的apt-get的安装,仅其他distrota PEP8致力探索神奇的是如何发生的. 在第二生成菜单按钮 (至少对我来说) 是皮棉后单击你会发现他多么丑陋的代码,您创建了 😀

从截图 2016-01-11 20-42-21

这基本上是如何使你 Geany 工作更好地与 Python 和在同一时间,继续将快速掘进的 CPU 要拉子弹.

若要更改域在 WordPress 是有些疼痛. 最近我不得不做了其中的一些和一切发生快速运动 😀 . 如果我可以的 sumariziram 的步骤 2 – 自然没有移动文件, 如果更改的设置完全托管.

1. 更改新与旧的 URL – 这里的东西都是琐碎. 打开您的 URwp config.php 文件并将其粘贴在以下 2 线

define('WP_HOME','http://example.com');
define('WP_SITEURL','http://example.com');

作为替换 http://跟你的新链接.

2. 该网站现在是打开 url 工作但已上载的内容,如图像, 文件等等是不可见. 这里现在的干扰. 你需要用数据库中的新 url 替换旧. 这是一个非常麻烦的过程,特别是对于初学者用户, 谁不好与 SQL 语法呢, но вече има доста приятен скрипт searchreplacedb2, 这对你来说很不舒服. 它的使用是微不足道 – 将其上载到 wordpress 的目录根页面和在您的浏览器中打开它. След това следвате стъпките като първо ще ви пита за потребителско име и парола който е взел от вашия wp-config.php и след това ще ви пита за новото и старото url. След последната стъпка ще се наложи да поизчакате при мен отнемаше средно 40сек -50сек.

Това е във общи линии нищо трудно или супер сложно.

A shell script wants your job

Днес докато работех видях че една от машините лагна много жестоко. Влизам в нея гледам един cron наблъскал адски много зомби процеси (грубо около 50-60). Нямаше как да ги убия всички с killall затова се наложи да направя малко по грамотно решение на проблемада драсна едно елементарно 庆典 скриптче което да намери и убие процесите. 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. Обаче не е много добра практика да има много такива чести случаи 😀 Но никога не пречи да сме предпазени от всякакви шитни

通过增强Zemanta

Image representing MySQL as depicted in CrunchBase

Преди известно време бях писал за MySQL 全文搜索 🙂 Днес имах много интересно преживяване с една заявка. В общи линии заявката търси за резултати който липсват друга таблица. Един основне Select и един sub select в WHERE частта на заявката. В общи линии скелета и е

SELECT DISTINCT (
`field`
)
FROM `table1`
WHERE `someID` =44
AND `firsTextField` NOT
IN (

SELECT DISTINCT (
`secondTextField`
)
FROM `table2`
WHERE `otherID` =44
)

В общи линии елементарна заявка. Написах я за 30 сек пускам я и зацикли машината. След дълго и търпеливо чакане от моя страна или по точно ~43 сек . Ми се изплю резултат lol . Пффф лудница. Влизам в машината гледам процесора е нормално натоварен почти в idle състояние. Шок и ужас. Пускам пак заявката пак същия резултат. Fuck WTF. Пускам explain на заявката и всичко лъснавторото поле secondTextField е само full text search без index, а там табличката е скромна от около 35к реда. Кой да четеfull text search не е индекс. Вече е ясен проблема набързо едно

ALTER TABLE `links` ADD INDEX ( `linkUrlID` ) 

И нещата си дойдоха на местата Query took 0.0005 sec 😀

Внимавайте как си слагате индексите от тях ви зависи маргинално скоростта на заявката.

p.s Като цяло аз съм си крив за горната ситуация не само защото липсва индекс ами защото не ползва full text search метода 😀

通过增强Zemanta