Web APIを利用して簡単な英和辞書機能を実装してみた。
プログラミングの学習をしていると、どうしても英文を読まないといけないときがあって、
分からない単語にぶつかる度に検索するのが面倒だった。
なので、あらかじめ英文を用意してそこに含まれる単語の訳を一覧にできないかと思ってちょっと作ってみた。
結果から言うと、その機能は断念した。
#! /usr/bin/python # -*- coding: utf-8 -*- import urllib2, json def translate(phrase): from_ = "en" dest_ = "ja" api_url = \ "https://glosbe.com/gapi/translate?from={0}&dest={1}&format=json&phrase={2}&pretty=true".format(from_, dest_, phrase) res = urllib2.urlopen(api_url) # この段階ではまだ文字列形式なので、 # json.loadsメソッドで辞書型へと変換する。 js_data = res.read() js_dict = json.loads(js_data) result = {} temp = [] tuc = js_dict['tuc'] for i in range(len(tuc)): try: temp.append(js_dict['tuc'][i]['phrase']['text']) except KeyError: continue result = {phrase:temp} return result if __name__ == "__main__": result = translate("apple") for _, v in result.items(): for val in v: print val.encode('utf-8')
jsonのパースのとことか、検索単語を直で扱っているあたりとか、いろいろあれだけどとりあえず訳はでる。
本当だったら、入力された英文を単語毎にまとめて訳を出力しようと思っていたのだけど、
Web APIを利用させてもらっている手前一単語ずつアクセスするのが憚られたので、それは断念した。
予め自分の知らなそうな単語だけをピックアップして、その単語だけ検索かけるみたいなこととかできればなと。
もしくは、時間を空けて断続的なアクセスをするようにするとか。
そこら辺の作法的な部分も抑えておかないと。
参考にさせていただいたサイト
英単語の日本語訳をプログラム内やターミナル内で取得する - roombaの日記
利用させて頂いたAPI
本当に簡単な機能だけど、Web APIの使い方や（めたんこ下手だけど）jsonのパースとか
Pythonの構文を学ぶだけじゃやらないようなことを学べて楽しかった。
合わせて、Pythonエンジニア養成読本でbottleを使ったWebアプリケーションの作成もやってみたので、
ちょっとずつだけど、いろいろなことを出来るようになってきた気がする。
それでもまだまだ全然知らないことばかりだし、全然へっぽこだけど。
年明け前からずっといろいろとやってきたけど、やっぱり継続することが大事なんだと思う。
毎日ほんの少しずつでも、何かしらをやってみて、それが知らないうちに自分の知識や経験になっているのだと。
へっぽこだけどへっぽこじゃなくなるために、これからも続けていく所存であります。
過ぎた欲は身を滅ぼす。
文庫版が発売されてからだいぶ経ってしまったけど、真山仁さんの「グリード」をやっと読んだ。
強欲は善、ではあるが過ぎた欲は身を滅ぼす、というのが率直な感想。
サブプライムローン全盛のアメリカが当時、実際にどんな状況にあったのかわからないけど、
渦中にいた人たちはずっとその好況が続くんだろうなぁと思っていたんじゃないか。
その十数年前には、日本が経験したように。
人間は自分の信じたいものしか信じないし、聞きたくないことは聞かないし、
見たくないものはきっと見ない生き物なんだろうけど、
ちゃんと現実を見据えられる人がいないと駄目なんだろうね。
現実を見据えてちゃんと行動できる人。
ハゲタカシリーズを読むたびにこういう目まぐるしい状況が今現在進行中であることを 思い知らされるし、いつ自分がその渦中に巻き込まれるか分からないことを実感させられる。
そんな状況にいても楽しんで乗り越えられたらなと思う。
近況
最近は業務が忙しかったり、体調を崩しがち。
やはり健康第一じゃないとだめだ。
初めてのPythonもようやくクラスのとこまで目を通した。
ただ、関数あたりからメモる量が格段に増えてブログに載せきれないというか途中からメモを断念してしまった。
まぁ、また再読すると思うからそのときに再度メモってみよう。
最近やっとPythonのちょっと深いところまで理解できてきたので、
そろそろ何か実践的なことをしたいなぁと。
そう思ってbottleのチュートリアルやってみた。
Djangoと違って軽量フレームワークだから、さくさくと進んで、 ローカル環境だけど簡単なto doアプリケーションの作成ができた。
bottleの良いところは公式ドキュメントの英語が簡単でわりとさくさくと読めるとこと、
bottle自体が１つのモジュールで構成されているから、ソースもわりかしと読めるとこかな。
まぁ、全然理解はできてないんだけど。
そんな感じでがしがしと何かを作っていきたいと思うこのごろ。
初めてのPython再挑戦2
初めてのPythonのメモがき。
今日はステートメントの部分のポイントをまとめる。
条件の評価式の際には()は任意
a = [] in not a: print a #空のリストが表示
代入ステートメントについて
代入は変数とオブジェクトリファレンスを結びつける操作のこと。 変数はオブジェクトリファレンスを保持するのみであり、 型情報はあくまでオブジェクト側で保持されていることに注意。
形式
- シーケンス代入
a, b, c, d = "spam" print a # 's'と表示 print b # 'p'と表示
左辺の変数の数と、右辺のシーケンスの要素数が一致しないとエラーなる。 そういう場合は、スライシングを利用すると良い。
str = "spam" a, b, c = str[0], str[1], str[2:] print c # 'am'と表示
- マルチターゲット代入
複数の変数に同一のオブジェクトリファレンスを保持させることができる。
a = b = [] # a b ともに空のリストの共通リファレンスを保持する a.append(1) print a, b # ([1],[1])と表示 b.append(2) print a, b # ([1, 2], [1, 2])と表示
- 拡張代入ステートメント
いわゆる、+=や/=なやつ。
演算対象が可変オブジェクトである場合、ちょっと変わった振る舞いをする。
L = [1,2] L = L + [3] # リストの連結 このとき新しいリストオブジェクトが生成され代入される L = L.append(4) # appendを利用すれば元のオブジェクトの上書きをする
新しいオブジェクトを生成するか、上書きをするのか挙動が変化する。 このとき、拡張代入ステートメントを使用すれば、処理系が自動で実行速度で高率な方を採用するため、 あまり考えなくてよい。
printステートメント
オブジェクトのデータをテキストに変換して標準出力ステートメントに書き込むステートメント。
標準出力の変更
sys.stdoutにwriteオブジェクトを備えたオブジェクトを代入すれば、printステートメントが リダイレクトされる。
>>でもリダイレクトは可能であるが、これは一度キリなので、何度もリダイレクトしたい場合は
sys.stdoutを弄った方がよい。
forループ
forステートメントを使用しないループ処理の書き方もある。 処理対象のオブジェクトをiter()に渡すと、イテレータオブジェクトを返す。 そのオブジェクトに対して、nextメソッドを実行すると、要素を返してくれる。
L = [1,2,3] I = iter(L) # 反復処理に対応したオブジェクトを生成 I.next() # 1を表示 要素がつきるとStopIteretion例外を発生させる
リスト内包表記
メリットとして、コードが簡潔になる。 また、処理速度もforループを使用したときよりも高速になる。 これは反復処理がPythonのコードレベルではなく、インタプリタの内部で Cのコードレベルで実行されるから。 デメリットとして、いくらでも拡張することができるため、複雑な処理を記述すると可読性が落ちてしまう点。
幸せなシステム開発って何だろうって考えたこと。
大層なお題目をたててみたけども、単なる愚痴に落ち着くんじゃないかと最初に述べておく。
最近関わっている仕事で、幸せなシステム開発って何だろうと思うことが多くて、 自分が普段不満に感じていることと、じゃぁどうすればいいの？？ってとこをまとめてみたいと思う。 自分の今の職場がメインフレーム相手に開発してるという前提でのお話となります。
ドキュメントやソースコードのバージョン管理がされていない
これは今に始まったことじゃないんだけど、バージョン管理っていう概念がない、とまでは言わないけど バージョン管理ツールを用いて管理するっていう考え方がない。 エクセルの仕様書はリネームしたり、もしくは修正ページだけ記載したり、色をつけたりで管理したりする。 ソースにいたっても同様で、差分をとれるのは前回との差分、もしくは本番ソースのみ。
だから、頻繁に修正なんか入ったりすると、いつ、誰が、何のために、どんな修正したのか ということを人力で判断しないといけない。
今ならgitやSubversionでも導入して、管理していければいいんじゃないかなって思う。 もちろん、Web系の開発をしているチームでは当然に行われているけど、 いわゆるホスト系（メインフレームでの開発）のチームでは行われていないのが現状。 というか、必要性を感じていないのかなぁ。そういう声全然聞いたことないし。
適切な設計に基づいてソースが書かれていない
これはWebとかホストとか全く関係ないとは思うんだけど、いかんせんソースコードがばかでかい。 ひとつの機能を果たすモジュールのはずなのに、最終アウトプットを出力するための中間処理とかも そのモジュールに組み込んでいて、何がどこでどのように行われているのか全然わからない。 そしてグローバルスコープ万歳の状態。
そういうプログラムに限って、非常に重要な機能を果たしているため、 ちょっと修正するだけでも戦々恐々しながら修正している。
これは何だろうなぁ、、、自分もたいしたスキルを持っている訳じゃないから たいした事は言えないけど、オブジェクト指向とかデザインパターンとかリーダブルコードとか 良い設計の仕方、良いソースコードの書き方とか学んで行くしかないのかなぁって思う。
結局は開発者のスキルを高めることが大事なのか。 そういう意味ではスキルとか高めていこうっていう風潮ないんだよなぁ... いや会社としてはそういうことを謳っているのではあるんだけど、実際に働いている人がなぁ...
納得感のない開発
プロダクトが実際のお客さんに喜ばれるかどうか、逆に喜ばれないんじゃないかと思う開発を実施すること。 そういうプロダクトに限って非常に複雑な仕組みの商品で、システムの実装も非常に苦労するし、 こういうの作っても本当にお客さんに喜ばれんの？？って思いながら開発するのは本当につらい。
んーこれはある程度の規模の会社になったらしょうがないのかなって思う。 誰もが納得するプロダクトって難しいよね。
とまぁつらつらと書いたけど
結局は、プロダクトが自分の納得がいくもので、会社としてもこういう状況だからこのプロダクトが必要なんだ、
とちゃんと説明してくれて、開発レベルでいえば適切な開発フローと開発ツールが用意されていて、ソースが汚くても
ちょっとずつリファクタリングしていって、奇麗にしていこうみたいな心構えがあれば幸せなんかなぁって思う。
いやまぁ、そういう会社って少なくない？？理想高くない？？って思うけど、別に開発フローやツールは自分たちで用意していけばいいし、
そもそもリファクタリングなんてCIツールやテストの自動化が前提にあると思うから、やっぱり納得感のいく開発が
できることが幸せなシステム開発の根幹なのかなぁって思った。
あとはあれか。会社としてもそういうのを許してくれる会社か。お金出すの会社だもんね。
そういう意味では、正しいタイトルは「企業に勤めるうえでの幸せなシステム開発」か。
全然まとまってないけど、とりあえず自分の中で大事だろうなぁって思ったのでまとめた次第です。
初めてのPythonに再挑戦。
dir関数
dir(module)
モジュール内で利用できる属性のリストを返す。
名前空間
変数（名前）の集合のこと。 Pythonはモジュール毎に名前空間が設定されていると言える。
Pythonにおける変数
変数は代入されることで初めて作成される。 また、変数に保持されるのはオブジェクトのリファレンスであり、 オブジェクト自身にオブジェクトの型情報や、被参照数（リファレンスカウンタ）、値を保持している。 このリファレンスカウンタがゼロになったさいに、ガーベージコレクタによって、 オブジェクトのメモリスペースが解放される。
静的型付言語では、変数にも型情報を保持していることになるのかな？？
同等と同一
同等とは、オブジェクトの値が同じであること。 ==演算子を使用。
同一とは、変数のリファレンスが同じであること。 is演算子を使用。
ディクショナリを用いての文字列フォーマット
"" %(id)s : %(name)s " % {"id":"0001", "name":"taro"}""
キーを文字列に埋め込んで、フォーマットすることも可能。
ディクショナリについて
写像とは、要素にキーが割り当てられたオブジェクトのこと。
リストは、オブジェクトリファレンスの配列であるが、
ディクショナリは、オブジェクトリファレンスの順不同のテーブル。
ハッシュテーブルで実装されている。
リファレンスが保持されるという点では、一緒。
shallow copy と deep copy
shallow copy
[:]やdict.copy()でコピーされるのは、トップレベルでのオブジェクトのみ。
なので、ネストされていた場合、そのオブジェクトのコピーはされない。
deep copy
copy.deepcopy()を利用すると、ネストされたオブジェクトリファレンスもコピーされる。
が、あまり使用しないらしい。
