さくらのSSL
Related posts
gunicornの設定
djangoで何か作って運用するための準備としてgunicornを使ってみた。 gunicorn トップページには簡単に動きまっせみたいなことを書いているが、3晩はかかった。仕事だとしたらば1日潰れたぐらい時間がかかった。 まずはvagrantで動いてるubuntu 14.04にインストール つづいてサンプルアプリの写経 ~/src/gunicorn/myapp/myapp.py 動かしてみると、おー動く。 でもブラウザからは動作はしない。vagrantのポートフォワードの設定をしてもダメ。webサーバ、うちの場合はnginxの設定も必要らしい。 gunicornのインストール | i2bsの日記 なんとなく真似てgunicornのグループを作成して、vagrantユーザを所属させてみたが、結局confの設定は正しく読めなかった。 nginxの設定もunixドメインソケットのupstreamの設定がキモっぽいがsite-available/defaultに書いてると、/var/log/nginx/error.logに以下のエラーが出てnginxが起動しない。 ググってみるとどうもバーチャルホストの設定が必要らしくconf.d/になんか書く必要があるとのこと。参考にさせてもらったサイトでもよくみるとそうなってたので、そのようにした。でもconf./dの設定とsites-availableの設定の関係性が分からなくなった。 confの設定がどうも効かないので、CLIから直接起動。アプリを書いたディレクトリで、以下を叩く。 今度はListeningのlogが変わった。 がしかし、http://127.0.0.1:18000/にアクセスすると、gunicornのアプリがエラーする。(18000はvagrantへのhttpアクセスのport forwardの設定port) “gunicorn type error not a byte”でググって、stackoverflowで解決。 gunicorn (Python3.4 and 3.3) sends in response only headers without data | stackoverflow 元のアプリがpython 3系だとダメらしい。以下のresponseとおぼしき1行を修正してブラウザからの動作は確認できた。 – return iter([data]) + return [bytes(data, ‘utf-8’)] 残すは設定ファイルからのgunicorn起動。 2015/10/05追記 設定ファイル書けた。たぶんファイルのパーミッションの問題で、daemon化ができていなかった。以下は動作が確認できたファイルで、logファイルは先に作成して、chmod 666した。 なお確認したソフトのバージョンは、以下。 python 3.4.3 nginx 1.4.6 gunicorn 19.3.0
ソフトウェア業界(受託開発)
先日お客様との新規商談に出席したときに私が思った話です。 商談にて私の先輩が発注元の別プロジェクトで長年のパートナーシップ、つまり信頼をアピールしていました。また、別の案件にてパートナーさんから派遣での協力が必要になり、懇意にしている会社様に連絡をしたのですが、スキルシートをみたところ期待通りの提案ではなかったです。 一見関係のない話ですが、私の会社(の私の属しているセクションのビジネス形態)はずっと同じポジションにいることと、私が契約しているパートナーさんはポジションが変わっていると思われます。私のセクションは長年の信頼=受託開発を長くやっていて人月ビジネスから脱却できていないですが、私のパートナーさんは派遣から始めて請負契約に変更、直請と人月ビジネスでより高い単価の形態へシフトしていっているのだと推測します(そのため派遣契約では今までと同レベルの提案が出ない)。 受託開発・人月ビジネスの世界といえど、日進月歩な世界と近いポジションにいると思います。長年の信頼と実績を謳うことは受託開発からのステップアップができていないことを暗に示しているような気がしました。
pythonその6 django入門
ルーティングがうまく行かないなーと思って、和訳を眺めてたら衝撃の事実が… 自分の間違い:mysite/polls/urls.py を新規作成 正しくは:mysite/mysite/urls.py 既存ファイルにルール追加。 と思いきや1.4と1.8だとurls.pyの置き場が違うみたい。重要そうなファイルなので、公式ドキュメントの間違いなんじゃないか?と思い試行錯誤した結果、ようやくでけた。polls/urls.pyは新規作成で、mysite/urls.pyは修正。両方必要みたい。公式もよーく読むとそう書いてあった。ルーティング定義をしてるのに404 not foundで、定義したルールとエラーしたルールが違う時点で気づける人は気づけるんだろう。 railsと比較すると自分で書いてる分、コントロールできている気がすると思うし、どうせできてるといってもscaffoldだと実際には使えないしなーと思う反面、いちいち書くの面倒くさいなーとも思ったり。また、がちゃがちゃやってる間にいろんなエラーに出会った。 ImportError : from x import yの誤り SyntaxError : 括弧の数が合わない IndentationError : インデントが合わない NoReverseMatch : “XXXX is not a registered namespace”と詳細で出てる。どうもチュートリアルにあるnamespaceの指定が余計っぽい。 AttributeError : module’ object has no attribute ‘XXXX’ タイプミスを指摘された。 この辺のデバッグは慣れが必要だな… チュートリアルの4ではそれまでとガラっとviewの書き方が変わる。今回はローカルのgitにこまめにコミットしながらやってたので、ビクビクせずに学習できたが、classベースのviewに変えたら、最新5件をとってきてindexに表示するところが動かなくなったので、後で調べる。たぶん。 2015/08/29追記 classベースのviewでindex表示ができない原因はtypoだった。contextと書くはずが、conextになっていた。
Trackbacks and Pingbacks on this post
No trackbacks.
- TrackBack URL
Comments on this post