DN42は、BGP-破壊的な製品環境なしであなたのスキルを開発することができます素晴らしいプロジェクトです, あなたはGNS3でのシミュレーションを行うための実験室を行うと高価な機器を持ってすることなく、. 何の実世界の問題はありません、純粋な実験環境ながら、. に参加 1 およそ年間のプロジェクト内のノード. プロジェクトにおける問題の一つ 1:1 現実の世界で – 誰かが発表されたときに接頭辞が発表されてはなりません. 私は怠け者だと私はまだ時間が手書きのフィルタをしないので、, 私はプレフィクスリスト名dn42を生成するシンプルなbashスクリプトの問題を解決し、それが有効な接頭辞を注ぎます.

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

有効なprediksiのリストには、HTTPSを取ります://ca.dn42.us/reg/filter.txtメインコンベア + 私の部分にはほとんど変更は、プレフィクスリストを生成することができるようにします. コマンドはvtyshで実行されます.

私の好みのテキストエディターです。 Geany. 彼は非常に最小限 IDE 言語の巨大な範囲をサポートします。 – シェル, PHP, python, C … など. あなたの自動車-完全な同時に機敏そう. 彼は気持が良い機会を欠けているが、時に、私には十分以上. オンライン コースを開始しました。 Python プログラミング SoftUni の – 私の知識を更新し、私は続いている適切に python で起こるので nadgradâ を作る 3. スピーカーはもちろんお勧めします。 PyCharm pyton プログラミングの IDE として, しかし、私は私の好みから遠く, 当然のことながら演習 Geany を使用します。.

講義中に痛みを感じた 2 リプスィ島

  1. python オートコンプリートと関数やメソッドのドキュメントを息を吐き出す
  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 でインストール pep8 魔法のしくみを発見する他の distrota 作品. [ビルド] メニューの 2 番目のボタン (少なくとも私に) クリックすると、😀 を作成したどのように醜いコードが診て後糸くずは、します。

スクリーン ショット 2016-01-11 20-42-21

これは基本的にどのように Python と同時に、良い仕事、高速の弾丸をプルする CPU を運転であり続ける、Geany.

ワードプレスのドメインを変更するのにはいくつかの痛み. 最近これらのいくつかをしなければ、すべて発生速いスポーツ 😀 . 私は sumariziram することができる場合は手順が 2 – ファイルを移動せずに当然のことながら, 設定が変更された場合完全ホスティング.

1. 新しい古い URL を変更します。 – ここでの事は些細です. URwp config.php ファイルを開き、次のように貼り付けます 2 ライン

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

Http に置き換えられますように://あなたの新しい example.com.

2. サイトは現在画像などのアップロードされたコンテンツが url を開く作業です。, ドキュメントが表示されません。. ここ今干渉. データベースで新しい url で、古い交換する必要があります。. それは特に初心者ユーザーのための非常に厄介なプロセス, SQL 構文をよくしない人, но вече има доста приятен скрипт searchreplacedb2, あなたのためが不快になります. その使用は簡単です。 – ワードプレスが、ページ ルート ディレクトリにそれをアップロード、あなたのブラウザーで開く. След това следвате стъпките като първо ще ви пита за потребителско име и парола който е взел от вашия wp-config.php и след това ще ви пита за новото и старото url. След последната стъпка ще се наложи да поизчакате при мен отнемаше средно 40сек -50сек.

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

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. Обаче не е много добра практика да има много такива чести случаи 😀 Но никога не пречи да сме предпазени от всякакви шитни

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の強化されたことにより、