スイーツ（笑）と呼ばないで!!
|
| |||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
11/24/12:27 [PR] |
12/22/11:50 macとpythonmacとpython
macとpython(マックトパイソン)・・うん、マイケルジャクソン的な響きだ。 誰にも初めての瞬間がある。 昔はいろんな書籍とか参考サイトとか見ると、Javaでサンプルが書いてあることが多かった。 でも、最近、割とこみいったことをやろうとしてサイトを見ると、Pythonで説明されているのに遭遇することが多い。 もちろん、一般的な話ではなくて、どういった分野に興味を持って情報を探しているかによるだろう。 そこで、昨日の深夜1時ごろにふと思い立って、Pythonの基礎的なところを試してみようと思い立った。 で、環境は・・というと、我らがMacはやはりこの点もイケていて標準でPythonは使えるようになっていた。 vi tesy.py としてエディタを開き #coding: utf8 print ‘Hello World’ として保存し、 python test.py とすれば、もうHello Worldはクリア。 で、まぁ、if文だfor文だというのは、他の言語と方言といえるほどの違いもないので簡単にマスターできる。 きっと、次にはまるのはDBとの接続だ。 やっぱり本格的にアプリを作りたいとなるとDB接続は外せない。 で、いろいろ情報探すと、pipとかってのを使っていれるとか書いてある。 brewでいれると、どうやらpipもついてくるようだけど、 いまのところmacに最初から入っているPython使っているので、 ここで brew install python とかやると、mac上にpythonの環境が二つできてしまう。 そこで、とりあえず、コネクタだけ落としてくることにした。 あ、macにmysqlをインストールしているのは大前提。 brew instal mysql とすればとりあえずMySQLの5.7がはいる。 そしたら最新のmysqlとpythonのコネクタを落としてくる。 wget http://cdn.mysql.com/Downloads/Connector-Python/mysql-connector-python-2.1.3.zip 解凍とインストール unzip mysql-connector-python-2.1.3.zip cd mysql-connector-python-2.1.3 sudo python setup.py install これで無事インストール完了。 早速テストコードを書いてみる。 (mysqlにテスト用のテーブル作成するところとかは本筋とずれるので割愛) まず、接続用のconfigを作る vi config.py として #coding: utf-8 user = ’tsetmysqluser' host = 'localhost' passwd = ’testpassword1234' db = ’testdatabase' とか書いておく。 で、 vi testtest.py とでもして #coding: utf8 import mysql.connector import config dbconnection = mysql.connector.connect( database=config.db, user=config.user, password=config.passwd, host=config.host ) dbcursor = dbconnection.cursor() dbcursor.execute('''SELECT * FROM test1234''') for row in dbcursor.fetchall(): print row こんなコードを書く。 python testtest.py と実行すると、ターミナルには無事テーブルの中身が表示される。 いや、python的にいけてるかとか全く知らない。 だって、今日初めてpython触ったんだもん。。 ただ、どんな言語でも、制御文(ifとかforとか)と、出力命令(printとか)と、DBの接続ができれば、とりあえずサンプルアプリをどんどん書けるようになる。そしたら、自分が作りたい機能に応じて周辺知識を増やしていったら良いね。 ということで、皆、最初はHello Worldから始めるということで。
PR
|
12/21/18:02 Macに声をかけてもらいたい時SF映画を見たりすると、コンピュータが話をしているシーンに遭遇する。 昔はわざわざ録音した音声を流していたりしたけど、 今は、音声合成という技術が使える。 昔は専用のソフトとかインストールする必要があったけど、 今はOSとかに標準でついていたりする。 それも、英語だけだなく、最近では多言語対応が盛んだ。 我らがMac OS Xも日本語対応して数年になる。 とはいえ、なかなか日本語で音声合成することはあまりない。 英語のサイトみていて、英語で音声合成して読ませるとかはあるけど。 ただ、時々、最初に書いたようなSF映画なんかを見ると、 メールの着信だけでなく、メールの内容も読み上げてくれないかなー、なんて思う。 今日はそんな仕組みをMacで開発する時の話。 昨日ちょうどそんなSF映画を見ていろいろ試したのでそのメモをまとめてみる。 まず、結論からいうと、Macにはsayというコマンドがある。 say ‘Hello’ と書くと、HelloどMacが発音してくれる。 ここで大事なのは、音声合成にどのVoiceを選択しているかだ。 システム環境設定 > 音声入力と読み上げ の「システムの声」で選択できる。 ここで「Kyoko」とか「Otoya」とか日本語音声を選択していると、 上記の「Hello」もきっちり日本人的な発音をしてくれる(笑) ちなみに、私が好きな英語音声はAllison。 で、これだとインタラクティブな操作が必要なので、メモで書いて音声合成しているのと変わらない。 そこでいろいろとオプションを指定してみる。 まずボイスの選択は-vオプションだ。 say -v Kyoko ‘こんにちは’ とやればKyokoさんが読み上げてくれる。 次に、速聴・速読に慣れている人は一般的なスピードだと遅くてイライラすることでしょう。 そんな時は-rオプションが使える。 say -v Kyoko -r 200 ‘こんにちは’ 1分間に200語を話すスピードということになる。 個人的には1分間に500語程度のスピードが好きだ。 ちなみに、MAXの設定は720語みたい。 1分間に720語は、一度聞いた文章ならストレスないけど、 初めて聞く文章だと聞き流しだと何個か聞き損じがあるかもしれない。 ちなみに、ざっくり調べた感じだと、ギネス認定の最速ラッパーは15秒で97単語、つまり、1分間で400語程度とか。 で、最後に、システム開発で利用する場合には、文章を動的に変更する必要がある。 リアルタイムに流そうとすると1音声しか準備できないので、 きっと先読みで音声ファィルに変換したいよね。 そんな時は、-fでまずファイルから読むべき内容を受け取るように指定する。 say -v Kyoko -r 500 -f email.txt こんな感じにするとemail.txtの中身を読み上げてくれる。 最後に、音声ファイルで出力するオプションは-oだ。 say -v Kyoko -r 500 -f email.txt -o email.aiff とか書けばよいね。 さあ、これで、準備はできた。 あとは表側のシステムを組めばよいね。 バッチ処理とかでメールボックスをチエックする。 メールがあったらその内容をテキストファィルに出力し、 それをsayコマンドを使って音声ファィルに出力する。 その上で 「メールを3件受信しました。読み上げますか?」 みたいに音声で呼びかけ、指令が出たら、順に音声ファイルを読み上げる。 どう? 映画であったワンシーンそのままでしょ。 プログラムだから、いろんな条件でフィルタしたりいろいろ好きにできるね。 プログラミングしながら、バックグラウンドでメールを読み上げなんてこともできる。 目を使う作業は一つしかできないけど、目と耳は別のことができるからね ^ ^ 時間は24時間しかないからねー 効率的に生きていきましょ。
|
11/25/13:53 メールログの解析(本日のOJTより)たまに、メールが届かないんだけど、とかって連絡があり調査をしたりすることがある。
今日は、そんな連絡を受けた部下とのOJTの一コマを紹介。 部下:「yamada@abc.comというメールアドレスに今朝7時に一斉送信されたメールが届かないらしいんですよね」 私:「なるほど。じゃ、エラーログを確認してみよう。サーバーにSSHでログインしてみて」 部下:「ログインしました」 私:「まず、ログはデフォルトだと/var/logの中にあるね。今回はmailの話なので/var/log/maillogを開いてみて」 部下: 「えっと、ファイルを開くのはcatコマンドですよね」 私:「そうだね、それで開けるけどそのままだと大量に表示されてしまうので、メールが届かないユーザーのemailアドレスで絞り込んでみよう」 $sudo cat maillog|grep yamada@abc.com 私: 「catコマンドでmaillogのファイルを開いた後で、パイプ(|の記号)でつないで、grepすれば良いね。」 部下: 「なるほど。結果を見ると確かにErrorとなっていますね。この人だけエラーになっているのでしょうか?」 私:「そういう時は、Errorという文字列でgrepしてみると良いね」 $sudo cat maillog|grep Error 部下:「なるほど….わっ! たくさん出てきましたね。何件くらいあるのでしょうか。」 私: 「そういう時は、wcコマンド(ワードカウント)に-l(ライン)というオプションをつけて実行すると良いね。そうすると行数を表示することができる。」 $sudo cat maillog|grep Error|wc -l 部下: 「なるほど。これで件数がわかるんですね。とてもたくさんありますね。あ、でもこれって同じ人宛のもありますよね。重複を排除したいですが、全部日時もバラバラだし整理するの無理ですよね。。」 私:「そういう時は、まずメールアドレスの部分だけを切り出すと良いね。そういう時に使えるのはcutコマンドだね。maillogはスペース区切りで項目がならんでいるから、-d(デリミタ)オプションにスペースを指定するね。そして、スペース区切りで7番目がメールアドレスだから-f(フィールド)オプションに7を与えれば良いね。」 $sudo cat maillog|grep Error|cut -d’ ‘ -f7 部下:「おお!!メールアドレスだけが表示されるようになりましたね。あとはこの時系列でならんでいるメールアドレスしかも重複ありのをどうすれば良いか。。。」 私:「そんな時はsort(並べ替え)コマンドを使うと良いね。これはアルファベット順で並べ替えてくれるよ。そして並べ替えた上で、uniq(ユニーク)コマンドを使えば、重複を排除したリストが手に入るね。先にcutコマンドでメールアドレスだけにして、sortで並べ替えているからこそuniqが有効に使えるんだね」 $sudo cat maillog|grep Error|cut -d’ ‘ -f7|sort|uniq 部下:「なるほどー。これで先方にエラーになっているメールアドレスのリストをお送りできますね。あれ、これ見ると@abc.comの人ばかりがエラーになっているようですね。@abc.comの人でエラーになっていない人っていますかね。。」 私:「そういう時は、grepで-vオプションを使うと良いね。これを使うと"含まない”という反対の絞り込みができるよ。つまり、-v Errorと書けばよいね。あとは、@abc.comを含むgrepを入れてあげれば良いね。」 $sudo cat maillog|grep -v Error|grep abc.com|cut -d’ ‘ -f7|sort|uniq 部下:「なるほど! お、この結果を見るとabc.comでもメールがエラーにならずきちんと送られている人がいますね。逆に、abc.com以外でエラーになっている人はいるのでしょうか。」 私:「それは、今度はabc.comの前に-vをつけて、Errorの前の-vを外してあげれば、abc.com以外でErrorのものが抽出できるね。」 $sudo cat maillog|grep Error|grep -v abc.com|cut -d’ ‘ -f7|sort|uniq 部下:「なるほど。そうやって応用すれば良いんですね。あれ?1件だけありますね。残念。。。あ、でもこれabc.COMとcomの部分が大文字になっていますね。これは登録したユーザーが間違っていますね」 私:「そうだね。ただ、それでもメールは届いたりするので間違いとは言えないね。そういう場合には大文字小文字を区別しない-i(ignore case)オプションをつけると良いね。」 $sudo cat maillog|grep Error|grep -i -v abc.com|cut -d’ ‘ -f7|sort|uniq 部下:「本当ですね。それだとabc.com以外でエラーになっているものの結果は無しとなりますね。ただ、0とは表示されないんですね。」 私:「人数を見たい場合は、最初の頃に教えたwc -lを使えば良いね」 ◎abc.com以外でエラーになっている人数 $sudo cat maillog|grep Error|grep -i -v abc.com|cut -d’ ‘ -f7|sort|uniq|wc -l 0人 ◎abc.comでエラーになっている人数 $sudo cat maillog|grep Error|grep -i abc.com|cut -d’ ‘ -f7|sort|uniq|wc -l 123人 ◎abc.comでエラーになっていない人数 $sudo cat maillog|grep -v Error|grep -i abc.com|cut -d’ ‘ -f7|sort|uniq|wc -l 3,123人 私:「ということで、ここまでのメールログの解析から、 abc.com以外のドメイン宛のメールは全て正しく送信されている。 abc.comのドメイン宛のメールでも正しく送信されているものがある。 ということがわかるね。それぞれのリストや人数も把握できるね。 例えば、人数ではなく件数を出したいなら、途中で追加したsortとuniqを削れば良いね。 こうやって、コマンドをいろいろと組み合わせると、解析不可能に思える膨大なログの中から真実を突き止めることができね。これはapacheのログの解析とかにも使える技術なのでいろいろ勉強してみると良いと思うよ。」 部下:「しかし、linuxのコマンドって、こんなことできるんですねー。感動しました!!」 というようなOJTを必要に応じて部下にやっていたりします。 実案件で困っている時は部下も必死ですので、その困っている状況をさっと解決できる技術を目の当たりにすれば勉強しようというモチベーションも少しは上がるのかもしれません。 今回登場したコマンドはコマンドリファレンスを見れば全部載ってますし、オプションも--helpというオプションつけて各コマンドを実行すればすぐに確認できますね。ただ、リアルに直面している問題に対してどう組み合わせるかというところは、やっぱり先輩についてOJTで教えてもらうのが一番手っ取り早いかもしれません。その上で復習をしっかりとね。 今日も偉そうに自画自賛してしまいました(笑) それでは、またいつか会いましょう^^
|
10/30/12:01 失敗から学ぶとは生きているといろいろと失敗をする。 未来の成功のためには失敗から学ぶことが重要だ。 プログラミングの話で言えば、バグとかイケてない書き方なんかは失敗と言えるだろう。 たまに、 「私は自分が書いたソースコードとか間違いとかあればどんどん突っ込んでもらいたいですね」 というような言葉を耳にする。 この言葉は、実はこの言葉を発する前にどのくらい努力をしたのかで解釈が変わってくる。 例えば、時間がないからと場当たり的に書き、そのコードを見せた後で、このセリフを言ったらどうだろうか?自分でも100点とは思っていないコードだ。 そこでツッコミが入っても、一瞬ムカっとすることはあっても、たいして悔しくない。自分の中で言い訳もできるから。 でも、その失敗からはあまり多くは学べない。 失敗から大事なことを学ぶためには、大前提として、本気で取り組むことが重要だ。 自分の中で極限まで力を尽くし、もう今の自分ではこれが作り出せる最高のものだ、というところまでやりつくす。 そこで初めて「これでもダメなところがあれば教えてください」と謙虚になれる。 そこまで本気でやったものに実際にツッコミが入ればとても悔しいし憤りも感じるかもしれない。 でも、それを乗り越えるからこそ次のステージにいけるものである。 本気でやって、それを叩きのめされるから良いのである。 本気でやっていないものを世に出して、ツッコまれまくるのは良くない。 いつしか失敗することになれてしまう。気軽に間違いを起こすことになる。 それでは成長スピードは鈍化してしまう。 失敗から学びたいと思うなら、プライドが必要だ。 プロとして中途半端なものは世に出すまい、というプライドが。 とはいえ、納期と予算の制約をきちんと守ることは最低限必要なので、 芸術家みたいにはいかないけどね。
|
10/02/12:32 クライアントがサーバーに入りたいと言ったら?最近、サクッと短いブログを書いています。
弊社では基本的にroot権限は弊社で管理していますし、 相当な事情がない限り、クライアントにサーバーへのアクセスを開放することはございません。 しかしながら、いろいろ大人の事情ですとか、 テンプレートと画像、cssなどについては自分たちで変更したい、 とかおっしゃるクライアントのために、開放せざるを得ないことは結構あったりします。 例えばクライアントがアクセスしたいディレクトリ構成が /var/www/project_name/private/client/template /var/www/project_name/public/client/css /var/www/project_name/public/client/image このような場合どうするでしょうか? 【レベル0】 「私たちがソースアップしているlinuxユーザーをクライアントに教えて使い回せば良いじゃん」 →ダメです。そんなことしたら、事故が起きた時の責任の所在も原因の追跡も困難になりますし、そもそも事故が起きる可能性がたかまります。 【レベル1】 「じゃ、プロジェクトのルートである/var/www/project_name/をホームディレクトリとする別ユーザーを作れば良いじゃん。その上で/var/www/project_name/private/client/と/var/www/project_name/public/client/にのみアクセスできるようにすれば良いよね。」 →ダメです。そもそもそれでは内部構造も丸見えですし、プロジェクトのルートにlinuxのユーザー管理に使うゴミファイル(SFTPを想定)がたくさん置かれることになります」 【レベル2】 「わかったよ。そこまでセキュリティとかうるさいなら、 /var/www/project_name/private/client/をホームディレクトリとするclient_privateと /var/www/project_name/public/client/をホームディレクトリとするclinet_publicという二つのユーザーを作れば良いよね」 →それなら必要なアクセス権はなくなるけど、管理が煩雑だよね。それにFTPでなくSFTPでいくなら上記のようなゴミファイルの問題もあるし。 【レベル3】 「じゃ、どうすればいいの?」 →clientというlinuxユーザーを普通に作成します。ホームディレクトリは/home/clientです。で、/home/clientの下に、/var/www/project_name/private/client/へのシンボリックリンクのprivateと/var/www/project_name/public/client/へのシンボリックリンクのpublicをはれば良い。SFTPでそれでアクセスすればセキュリティの問題も特にないし最小限でかつ必要なものについてのアクセス権はある。 ということで個人的にはこのレベル3の方法が良いのではないかと思っています。 たまに、クライアント用に複数のファイルアップ用のユーザーを作っているプロジェクト(特にクライアント内部での権限の区別はない)を見かけます。 まぁ、いろいろと事情があるんだとは思いますが、特に深い理由がなければ、このような管理も良いのではないでしょうか。
|