忍者ブログ
Admin / Write / Res
ちゃんとカテゴリ分けされておりませんので、 記事をお探しならブログ内検索が便利です。 ご活用くださいませー+.(≧∀≦)゚+.゚
ブログ内検索
カレンダー
10 2024/11 12
S M T W T F S
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
カウンター
アクセスカウンター
最新コメント
[11/22 รูปพวงหรีดแสดงความเสียใจ]
[11/22 ดอกไม้ งานศพ]
[11/22 ช่อดอกไม้ตามสั่ง]
[11/22 ร้านดอกไม้บรรยากาศอบอุ่น]
[11/21 Robertret]
最新トラックバック
プロフィール
+ハンドル+
y_ayamori(purple)
+職業+
IT系エンジニア
+すまい+
さいたま
バーコード
[1]  [2]  [3]  [4]  [5]  [6]  [7]  [8
私がPythonを学び始めた2011年ころはほぼ日本語のドキュメントや記事はありませんでした。
いまはだいぶ豊富になりましたね。
それでもまだ機械学習などバッチ的要素での活躍が多くWEBはなかなか採用が見られません。
そのため、PythonでWEB開発を使用とすると意外に情報収集が困難だったりします。
なので個人的に役にたったよーって一覧を載せておきすね♪


(認証などのシステムで)ユーザの作成や変更など
https://docs.djangoproject.com/en/2.2/topics/auth/default/

formクラスの基本的な使い方
https://eiry.bitbucket.io/tutorials/tutorial/forms.html

formとmodelが対になっている場合のPOSTデータのDB登録
https://djangobrothers.com/tutorials/memo_app/form/

フォームの表示方法まとめ
https://narito.ninja/blog/detail/98/

ラジオボタンを設置
https://qiita.com/xKxAxKx/items/284abc565715f2283fec

inputタグのhidden
https://dot-blog.jp/news/django-modelform-field-hidden/


拍手

PR
唐突にプログラムを作成してほしいという依頼が。
ちょこっと使いたいだけだから、過去に似たツールがあればそれでもいいとのこと。
確かに8年前くらいにそんなツール合ったような…

ってことで過去のツールでもいいよってなりました。
おそらくライブラリが足りないだろうから、それだけ入れれば動くんじゃないかなー、って楽観視。


実際動かしてみると。。。
    print e.message
          ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int e.message)?

ああ...orz
Python2系だ。。。(げんなり)

2系をインストールして、対応しようかしら?
ちょっと迷ったけど、800行くらいのソースなんだしprint文くらいかっこで括ろうよ!
というわけでprintを書き換えて再実行。

  File "C:\Users\s.ikota\Documents\000.develop\easy_crawler_rev3.4.0(開発中) - コピー\crawler.py", line 201
    raise UnicodeDecodeError, "Failed convert string."
                            ^
SyntaxError: invalid syntax
raiseの書き方が変わってる…
直して実行

    import urlparse
ModuleNotFoundError: No module named 'urlparse'

くっ!
import urllib.parse as urlparse に変えて実行。

今度は StingIO !
import io as StringIO


f.next()
↓
next(f)


raw_input()
↓
input('')

そろそろ心が折れてきそうだわ…
if isinstance(o, str):
    return o.encode('utf-8')
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'bytes' object has no attribute 'encode'
ん?
これはあれね、2系はbytesのことをstrと呼び、strのことをunicodeと呼んでいたからね。
一瞬なんで?ってなったわ。

return len(filter(lambda x: x, arr_text))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: object of type 'filter' has no len()
listで返らなくなったのよねー、filterとかmapとかさ。


と、いうことでこんな感じでした。
これはガチなシステムだったら2系からの移行は確かに躊躇するわね。

番外編。
with open(RES_FILE, "wb") as f:
2系のころはバイナリとして読み込んだ後、適宜unicode化するのが当たり前だったわね。
結局後続のdecode、encodeでコケるので、これもbをとるような修正をしました。

拍手

お客様要望によりFirewallは実施しないでほしいと受けた案件がありました。
理由は自社のIPがわからないから…
規模や、何らかの壁により情シスとうまく連携が取れない企業様はそれなりにいらっしゃいます。
強く説得したいところではありますが、今回はそのままにしました。
ですが…
案の定、ものすごいポートアタックを受けます。
そんな無法者はさすがにブロックしたほうがよいと判断し、ブロックすることにしました。
当方では下記IPから雑にsniffingを受けたのでブロックします。
とりあえず、IP制限は実施したいけど、日本以外全部、は大変だなとお考えの方など参考になれば幸いです。

103.89.89.205
109.248.9.9
111.230.192.23
112.85.42.0/24
113.108.72.2
115.238.245.0/24
115.88.201.58
116.31.116.10
118.123.15.142/24
12.133.183.226
122.226.181.0/24
123.249.27.172
125.212.207.205
125.65.42.0/24
142.93.22.237
149.202.10.227
165.84.191.236
180.76.176.4
182.61.44.11
193.70.6.197
201.235.245.224
202.126.46.39
221.217.48.187
46.188.16.55
5.188.10.156
51.223.47.100
58.218.92.33
61.184.247.0/24
61.184.247.2
81.192.31.134
94.23.145.124
95.156.31.74


検索タグ
セキュリティ、IP制限、iptables、ファイアウォール、firewall

拍手

とある案件でAPIを実装することになりました。
クライアント側とサーバ側でベンダー異なるのですが、サーバ側の実装を待たずしてクライアント側でテスト的にモックが欲しいとのこと。
Google先生に聞いてみたらRESTfulなAPIをサクッと作れるミドルウェアがあると聞いて!
nodeで実装されたJSON形式のファイルを取り扱えるみたい。
早速試してみました!!

# OSの確認
$ uname -a
Linux localhost 4.4.0-128-generic #154-Ubuntu SMP Fri May 25 14:15:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/debian_version
stretch/sid
# まず、環境を整えます
sudo apt install -y npm
sudo npm install -g json-server
ln -s /usr/bin/nodejs /usr/bin/node
npm install -g n
n stable
json-server -v
# ダミーデータを投入
cat << __ > db.json
{
    "prefecture": [
            {"id":1, "name": "北海道", "yomi": "ホッカイドウ"},
            {"id":2, "name": "青森県", "yomi": "アオモリケン"}
        ]
}
__
# そしてサーバを起動
json-server db.json --watch --port 80 --host 192.168.3.91&
# GETのテスト
curl http://192.168.3.91/prefecture
curl http://192.168.3.91/prefecture/1

# POSTのテスト
curl http://192.168.3.91/prefecture -d 'name=岩手県&yomi=イワテケン'
curl http://192.168.3.91/prefecture -d 'name=宮城県&yomi=ミヤギケン'

# DELETEのテスト
curl http://192.168.3.91/prefecture/3  -X DELETE
curl http://192.168.3.91/prefecture -d 'name=岩手県&yomi=イワテケン'
curl http://192.168.3.91/prefecture

# IDのインクリメントの法則を試してみる
curl http://192.168.3.91/prefecture/4  -X DELETE
curl http://192.168.3.91/prefecture/5  -X DELETE
curl http://192.168.3.91/prefecture

# 再びPOST
curl http://192.168.3.91/prefecture -d 'name=岩手県&yomi=イワテケン'
curl http://192.168.3.91/prefecture -d 'name=宮城県&yomi=ミヤギケン'
curl http://192.168.3.91/prefecture

なるほど、これなら簡単ね(*^^*)
ただ、POSTが必ずしも登録ではなく、リクエストの一環としてやってくることも多いのが少し悩ましいところね。

以上、JSON-Serverでした。

拍手

多くのデータを分散処理したいことが多々あります。
並列化は一筋縄でいかないことはシステムを組んでみようと考えたことがある人なら難易度は低くないことは容易に想像がつくと思います。
特に処理をプロセス間で重複させないためのシリアライズは手を焼く仕組みの一つです。
この話をメンバに相談すると必ずキューイングがやり玉にあがるのです。

そうキューイング信者が社内にいるのです…
何かとキューキュー騒ぐので、何もたいそれたシステムを導入しなくても実現できるんじゃない?
と思いまして、調べたところ、DBで簡単に実現できそうでした♪

参考:
https://lightgauge.net/database/sqlserver/962/

まず、キューとなるテーブルを作成します。
psql
DROP TABLE mq ;
CREATE TABLE mq (
    id serial, 
    message text, 
    primary key(id)
);
\q

次に、テスト用にキューを貯めていきましょう。
for i in $(seq 1000)
do
    value=''
    for i in $(seq 10)
    do
        value="$value ,('hoge')"
    done
    psql -c "INSERT INTO mq(message) VALUES('hoge') $value "
done


キューを払い出しつつ、キューを削除していきます。
DELETE FROM mq WHERE id = (SELECT id FROM mq WHERE pg_try_advisory_lock(tableoid::int, id) LIMIT 1) returning *;

ターミナルをいくつか立ち上げて、下記コマンドを投げまくってみます。
\rm /tmp/hoge
for i in $(seq 600)
do
    psql -c"DELETE FROM mq WHERE id = (SELECT id FROM mq WHERE pg_try_advisory_lock(tableoid::int, id) LIMIT 1) returning 'hoge', *;" >> /tmp/hoge
done

結果を確認します。
うまくシリアライズされていました。
grep DELETE hoge | sort | uniq -dc
   1189 DELETE 1


行ロックを取得しない版も投げてみます。
\rm /tmp/hoge
for i in $(seq 600)
do
    psql -c"DELETE FROM mq WHERE id = (SELECT id FROM mq LIMIT 1) RETURNING 'hoge', *;" >> /tmp/hoge
done

処理がシリアライズできていないので二重処理してしまい、後から処理したものは削除ができず、0件になっています。
grep DELETE hoge | sort | uniq -dc
     37 DELETE 0
   1138 DELETE 1

これでPythonのQueueクラスのようなキューイングシステムができました。

小~中規模程度にしか通用しなさそうですが、やれ、ミドルウェアが必要だの、
OSのバージョンアップが必要だの、大げさな話になるくらいならこれくらいライトに初めてもいいのではないでしょうか^^

拍手

Python2でもおおよそ動くと思うけどね。
もう2018年だし、そろそろね?2系は卒業しましょう。
と、いうことで、loggingでーす。
すぐ忘れるのでMyめもです。
今までは雑にルートロガーを使うことが多かったですが、Windowsで作業していると出力がSJISになっちゃうので。。。
慣れる意味でもちゃんとLoggerを使いましょう、という教訓。

import sys
from logging import getLogger, FileHandler, Formatter, DEBUG

APP_PATH = os.path.dirname(sys.argv[0])
TMP_PATH = os.path.join(APP_PATH, "tmp")
LOG_FILE_PATH = os.path.join(TMP_PATH, "logs")
LOG_FILE_NAME = "{}.log".format(datetime.datetime.today().strftime("%y%m%d%H%M%S"))
LOG_FILE = os.path.join(LOG_FILE_PATH, LOG_FILE_NAME)
LOG_FORMAT = ("\t".join(['"%(asctime)s"',
                         '"%(levelname)s"',
                         '"%(thread)d"',
                         '"%(module)s"',
                         '"%(funcName)s"',
                         '"%(lineno)d"',
                         '"%(message)s"',
                         ]))

logger = getLogger(__name__)
handler = FileHandler(filename=LOG_FILE, encoding='utf-8')
handler.setLevel(DEBUG)
handler.setFormatter(Formatter(LOG_FORMAT))
logger.setLevel(DEBUG)
logger.addHandler(handler)


拍手

firewalldに慣れないので、UFWをRedhat系で扱う場合。
2018/01/12 CentOS6用に作成
2023/11/27 AlmaLinux9用に更新

sudo yum -y update
sudo yum -y upgrade
sudo yum -y install vim wget make gcc-c++ perl

# https://launchpad.net/ufw/
ufw_ver=0.36
ufw_ms_ver=.2
ufw_url=https://launchpad.net/ufw/${ufw_ver}/${ufw_ver}${ufw_ms_ver}/+download/ufw-${ufw_ver}${ufw_ms_ver}.tar.gz


mkdir -p ${HOME}/src
cd ${HOME}/src
wget $ufw_url

tar xzf ufw-${ufw_ver}${ufw_ms_ver}.tar.gz
cd ufw-${ufw_ver}${ufw_ms_ver}
sudo python ./setup.py install
cd ../
rm -rf ufw-${ufw_ver}${ufw_ms_ver}
sudo chmod -R g-w /etc/ufw /lib/ufw /etc/default/ufw /usr/local/sbin/ufw

sudo systemctl stop firewalld
sudo systemctl disable firewalld

# ここからはrootユーザで
sudo su -
ufw disable
yes y | ufw reset
ufw default deny incoming
ufw default allow outgoing
ufw allow from 192.168.0.0/24 to any port 22
yes y | ufw enable
ufw status
# 検索タグ CentOS6 UFW iptables firewall AlmaLinux9

拍手

Ubuntu 16.04 (14.04 からの do-release-upgrade)

ちまたで流行りつつあるヘッドレスブラウザの新星として最近注目を浴びているChromeを使ってみようと思いました。

参考: https://qiita.com/meguroman/items/41ca17e7dc66d6c88c07

いうがままにインストールしてみたけど・・・ライブラリが足りないようで叱られてしまいます。
もしかしたら16.04のネイティブ版だと問題ないのかもしれませんが、アップデートによりバージョンを上げているのが影響しているのかも?
Ubuntuはいろいろ丁寧に教えてくれるので、エラー画面を読み解き、必要とされているパッケージを入れてみました。

# 2017/12/27時点
apt install gconf-service gconf-service-backend libgconf-2-4 gconf2-common libnspr4 libnss3 xdg-utils libnss3-nssdb libasound2 libasound2-data

# 2018/06/28最新
sudo apt install -y gconf-service gconf-service-backend libgconf-2-4 gconf2-common libnspr4 libnss3 xdg-utils libnss3-nssdb libasound2 libasound2-data unzip fonts-liberation libappindicator3-1 libxss1 libindicator3-7 indicator-application

# ヘッドレスChromeのインストール
curl -O https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo dpkg -i google-chrome-stable_current_amd64.deb
再度実行してみます。

# google-chrome-stable --headless --dump-dom http://blog.mor-maid.info > test.thml
[1227/100537.751273:ERROR:zygote_host_impl_linux.cc(88)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180.
なんかrootユーザだとご都合悪いみたいね。
正しいと思うけど(笑)

書いてある通り --no-sandbox をつければできるみたい。
同じように躓いている方がいたらご参考にどうぞ。

拍手

Linuxサーバのiptablesがきちんと設定できているか不安だったので、外部からポートチェックをしようと思いました。
そんなサービスいまどき溢れているかと思いきや、セキュリティの観点からか、あまりないんですね。
もちろん1ポートあたりのチェックはいっぱいあるのですが、65536ポート全部舐めるようなサービスはおいそれと見つかりませんでした。

ならば、自前で作成してしまえ、というわけです。
もちろん外部サーバがあればね(笑)

python

import csv
import traceback
from telnetlib import Telnet

host = 'check.your.host'

with open("result.tsv", "w") as f:
    w = csv.writer(f, delimiter="\t")
    for port in range(1, 65535):
        res = ""
        try:
            Telnet(host, port, timeout=2)
        except Exception as e:
            res = str(e)
        w.writerow([port, res])
        print(port, res)

拍手

ちょっと遅いネタだけど、目についちゃったので‥‥
http://blog.livedoor.jp/dqnplus/archives/1943704.html

まぁ、ホリエモンも大口叩いて注目集まれば勝ちなんでしょうけど。

コメントにもある通り、適正を度外視して誰にでもできる、となれば殆どの仕事が誰にでもできると思うけど。

だれでもなれる、ならわかるけどね。
誰でも「できる」は違うと思うわ。
そもそも「できる」の定義もしないまま話をしているので、正解といえば正解だと思うけど。
でもこれだけは言えると思うわよ?

本当に誰でもできる仕事は将来、AIやロボットに置き換わる。
そして保育士は置き換われない。

「人」でなければならない仕事は、本来価値が有るべき、と思います。

拍手

Copyright ©  アナログを愛するデジタル生活館 All Rights Reserved.
* material by Pearl Box   * Template by tsukika

忍者ブログ [PR]