arveltのソフトウェア技術メモ

Arvelt's software technology memo

Ansibleを使ってみた話

ansible python

Python製のプロビジョニングツールAnsibleを使ってみました。

 

サーバーで遊ぶようにさくらのVPS借りてるんですが、VPSだから作って壊してを繰り返すじゃないですか。なのでセットアップ用のシェルを作ってたんですが、だんだんメンテしんどい感じになっていまして。

ここらでひとつはやりのプロビジョニングツールでも使ってみようかと思ったのです。これ系といえばChefですけれど、Chefはオレオレルールが多すぎてどうにも肌に合わなかったのです。入門記事読もうとしても意味がわからない。そこでansibleを知って、sshで色々やるんだよ。っていうのを見て、なるほどわかりやすいそれだ！ってなったので使うことにしました。

 

arvelt/myserver-setting-ansible · GitHub

というわけで書いたんですけれども。

 

基本のき、ベストプラクティス、Galaxy、パスワードどうすん？　ていうことについてはReadmeにメモってあります。

それ以外だと。その渡すパスワードをコマンド叩いたときにいちいちタイプするのめんどいから、ローカルにおいてあるファイルにかいておいて、シェルで渡せばいいか、とか。Railsアプリ(ここではRedmine)のデプロイめんどくさすぎて、これに何の意味があるのか（哲学、みたいな感じになったりしていました。

 

そもそもReadmeにTipsとか書いてて、Readmeってそういうんじゃねえから！Wiki使え！っていう感じなんですがこれはこれで自分で見返すのが凄い楽なのでおすすめ感あります。

Wikiまでいくのめんどいです。みたいな。

 

しかし、プロビジョニングツールにすると言っておきながら、最初のトリガーがシェルになってるあたり微妙感があります。VPSのコンソールからOS入れたところから始まる、っていう想定なのでまずssh設定しないとansble通らないじゃん？ていうせちがらい事情があります。

そこらまで含めてがっちりできるのはChefをサバクラ構成したときなんでしょうかね・・・。

 

ですがベターシェルとして使うという観点でいくとかなり良いのではと思いました。OSごとの細かい話とか気にしたくないのでmoduleが吸収してくれているのがよいところだと思います。Galaxy bookもあるので共有できますし。と思ったらYUMとAPTとかあって、だからそういうの考えたくないんだよ！なめてんのか！とかなりますね。

 

というわけでansible。小・中規模のサーバー郡をプロビジョニングしたいとき、もしくは個人用サーバーのセットアップ等に使えばよいと思います。

 

pycon2014jpに行ってきた話

pycon python

所感

django-debug-toolbarよさげ

pyramigばかりでflaskみなくなったけどflaskオワコンなの？

ラズパイ面白そうだから買う

非同期ライブラリはtornadoがいいらしい

pythonパッケージツールのことがさっぱりよくわからない。結局どうしたらいいんだ。virtualenvいいっていうけど結局それの操作覚えないといけないので面倒くささは何も変わらないなぁ。

python3はGAE SDKが対応したら粛々と移行を行うと思います。それ以上も以下もない。

 

 

面白かった話

CH03 Djangoアプリケーション、パフォーマンスチューニング (ja) - YouTube

【発表資料】PyConJp 2014 「OpenCVのpythonインターフェース入門」と、その補足説明 | DERiVE コンピュータビジョン ブログ & メルマガ

Python を支える技術 ディスクリプタ編 #pyconjp - Qiita

CH15 Pythonではじめる野球プログラミング (ja) - YouTube

CH01 Opening~Keynote: Kenneth Reitz - YouTube

Pythonによる非同期プログラミング入門

パッケージングの今

 

 

メモの供養。内容保証なし

pycon2014jp 1day

@hirokiky
SQLを吐きまくるコードは誰だ
インデックス
キャッシュ
アプリケーション外

django-debug-toolbar
dbログ出力
Funcload


python, Raspberry Pi, arduinoで作る商品電力モニター
@kironono

らずぱいとあるどいのの通信
シリアル通信
RS0232C
TX,RX,GNDがあればいい

Firmata
python-firmata

pySearial

電力の見える化
電流センサー
あるどいの
　センサー制御
らずぱい
　あるどいのと通信
　Webアプリ
　データ保持

電流センサ
CTL-10-CLS

 

リファクタリングツール
flake8
docformatter
eradicate
unify
pyformat
jedi
Rope
Code Climate
Radon
Sentry

 

 

pycon2014jp 2day
pythonの非同期プログラミング
@checkpoint
非同期処理の選択肢
twisted
　イベント駆動型ネットワーキングフレームワーク
　TCP、UDP、SSL、HTTP、SSH、FTP
　Deferred使う
tornado
　Facebookが開発のOSS
　WebFW＋非同期通信ライブラリ
　高速
gevent
thread, multi process, etc
asyncio
　python3.4から標準ライブラリ入り
　アーキテクチャ
　Event loop
　Corutines
　Future, Task
aiohttp
　非同期の使い方としてよいサンプル

 

 

パッケージングの今
パッケージを使う・作る・活用
pypi
pip
virtualenv
pip
-pre
-allow-external
-allow-univerified
python3.4以降からpipを利用可能になる
ローカルサーバーからインストール
　pip install pyramid -f url
requirements.txt
--no-indexとかある
wheel
　pip install wheel
　pip wheel pyramid
setuptools
　パッケージングするための必須ツール
setup.py
　パッケージのメタデータを書いておく
　内部ではsetuptoolsやdistutilsなどを呼ぶようにする
ローカルPyPIサーバー
　pip install devpi
devpi
　travisとかでpip wheelしておいてwheelhouseまるごとVCSに入れてしまうようにする
　devpiをLANに立てておくとか、Wheelしておくとか
requirements.txtを分けると使い勝手がよくなる（依存ライブラリとオプションとか）

使う
　pipが細かく進化してる
作る
　setuptools
公開
　wheelを使うとよい

 

 

sqlacodegen

　DB schemeからSQLAlchemyのModelコードを自動生成
Start Bootstrap
morris.js
　棒グラフ・折れ線グラフ
HIGHCHARS
　散布図
セイバーメトリクス
　BABIP
　ピタゴラス勝率

YAPC2014に行ってきた話

yapc perl

行ってきたので感想とメモを書く。

 

所感

・Perl mongerが型を求めてGoやらJavaやらScalaに手を出している感じ面白い

・言語・ツール・環境の選択は適材適所大事。その判断をできることがプロだよね

・バイナリで一本で配布できるGoつよい

・Githubがlibgit2のラッパーであるSmokeからGit RPCに変えようとしているけど、やっぱり想像するより計測するべきなんだ！という強い気持ちを感じた。

・らずぱいに触りたい気持ち高まる

・Yapcは技術の話が半分くらいだけ。残り半分のうち、半分は自分語り、もう半分は内輪ネタ。そういうのは決まった人しか見ないブログとかでやるべきで、大勢の前に出てわざわざやるものではないと思う。

・ベストトークにPerlがないなんてことよりも内輪ネタゴリ押ししてしかもそれがウケる空気になってることは問題なのでは。初めて来た人が半分以上！とか言ってたのにそれでいいのかな。

・会場が狭く立ち見ばかりでしんどい。

・ 1000人クラスのイベントを大きな問題なく終らせたことすごいと思う。スタッフのみなさんありがとうございました。

 

 

自分が聞いたやつ資料へのリンク置く

Perl meets Real World // Speaker Deck

Go For Perl Mongers

Scala In Perl Company // Speaker Deck 

On Technological Selection // Speaker Deck

自然言語処理を支える技術 〜要素技術とPerlの活用〜 // Speaker Deck

Perl for Perl Mongers (YAPCに来た人は皆Perl Mongerでは？)

OAuth/OpenID Connectを用いてID連携を実装するときに気を付けること #yapcasia // Speaker Deck

趣味開発のためのVPS/クラウド活用術 // Speaker Deck

Git and GitHub at YAPC:Asia // Speaker Deck

JSON SchemaとAPIテスト / Naoki Shimizu - YouTube

 

以下メモ供養、内容保証なし

一日目

「Perl meets real world」

らずぱい

あるどぃの

あんしぼ

Webの人にはらずぱいおすすめ
　kano (子供向けのオールインワンのPCキット)
　GPIO コマンドからピンのon/offができる

Arduino
　単体ではそれほど。エコシステムがすごい

らずぱいとあるどぅのつかいわけ
らずぱい
　画像処理エンコード重たい処理
　複雑なアルゴリズム
　PC向けのライブラリを使いたい
　簡単なオンオフのハードウェア制御
あるどぃの
　自作の電子部品と連携
　あるづぃの向けライブラリを使う
　PWM制御とかしたいとき

ハードウェアのオープンソース
arduino自作のメリット
　機能の追加
　フットプリントを減少
　Arduinoのエコシステムの恩恵を受けたい

らずぱいとあるどいので連携
　Firmata
　ArduinoにFirmataを書き込む

ハードウェアを自分で作れる時代がきてる
IR kit


「Go for perl monger」

goはLLっぽいc

goに例外はない
panic recoverはほんとにダメな時
オブジェクト指向忘れろ
gormrutineはposixスレッドではない
例外とエラー
　panicとか使っちゃダメ
　複数の戻り値でerrorを返す
　戻り値のエラーは毎回確認
　panicはassretみたいに
　fmt.Errorがいい

構造体
　基本はcみたいな構造体
　継承がない
　合成は継承っぽく見えるけど委譲
継承せずに小さな部品を作る
それを無名埋め込みする
genericないのでinterface勉強しよう

オブジェクトっぽい階層を作るのではなく、フラットなAPIを作ることを考える

並行処理
　gorouten,channel
　deferの使い方とか

 

「Json Schema」
API結合テスト
JsonSchema
　jsonデータをjsonのschemaとして定義したもの
　データの検証に使える
json-fuzz-generator
　json schemaで記述された仕様から正常異常リクエストデータを生成する

 

「Scala in Perl Company」
Perlのエラー検知の限界
　思ってもない原因でエラーが起きる
　想定できるならエラーにならない
エンジニアが頑張ってコードを把握するしかないのか
継続的なソフトウェア進化の難しさ
安全性の確保が非常に大変
静的型システム使って安全性を高める
Scalaを選んだ理由
　表現力の高い静的型システム
　代数的データ型を定義できる
　記述の柔軟さ簡潔さ
　社内に書ける人がいる
コンパイル時間が長い
言語機能が豊富なので学習コストは高め

 

 

「いろんな言語を適材適所で使おう」
問題意識
Webアプリは大変になっていく
肥大化、複雑化、多様化
環境、言語、FW様々増えていくが適切に選択するためには
選択の目的
ユーザーに提供する価値を最大化するため
言語選択の決定要因
言語自体の特性
コミュニティ
エコシステム

サービス開発は時間との戦い
持続的成長
評価は一時的なものでしかない
移り変わる状況の下でその都度最適な選択を
変化への技術的対応
将来得られるだろう価値を見積もる
撤退して得られる価値より継続する価値が高いならば撤退する
microservices
SOAと違う
技術的分散・変化への組織的対応


「自然言語処理を支える技術」
ルールベース
　メンテがめんどい
　例外に弱い
統計的学習モデル
　パラメータの調整が難しい
　形態素解析
　自然言語文を形態素に分析すること
コスト最小法
　単語辞書を用意する
　辞書を利用して単語候補を列挙する
　単語を文頭から文末まで並べて組み合わせた構造を作る
　コストを設定する
　コストが最も小さな経路を探索する
動的計画法
Mecab
Trie

 

「Java for perl Monger」
Java結構いいよ

 

二日目

「Changing the tires on a moving car: a case study in upgrading legacy architecture」
githubのバックエンドの人

gitについて
gitはだぐ？である
git cat-file -p で親を辿れる
一つのリポジトリをホスティングするなら簡単
700万リポジトリ
500万push/day
一億pull/day
27ファイルサーバー
100TBストレージ
昔のGritはrubyのgitラッパー
2007/10/9 最初のgithub
GFFというファイルシステムを使ったがあまりスケールしない
Smoke というのを使っていた
linuxはBitkeeperからGitになった
使い方として共有ライブラリでいいのでは？
コマンドラインツールなのでWebで動かすには問題があった
そこでlibgit2が作られた
Jgit
Git-Raw
Git RPC
Git Smoke to Git RPCへの変更
Graphite グラフツール


「Oauth/OpenId Connectionに実装で気をつけること」
ソーシャルログイン目的
　利便性工場・経費削減
　Oauth Dance
　各サービスのSDK・言語の汎用ライブラリとか
　UI/UX
連携キャンセル次の挙動
　エラーなの？ユーザーの意図は？やっぱりやめたい？やりなおしたい？
　未登録ユーザーの扱い
　新規登録フローに誘導するとか
どこまで進めてよいか
　過去のログイン情報の取り扱い
　アイコン並んでると、どれ使ってたっけ？ってなる
　前回利用したサービスを保存して利用するとか
セキュリティ
　Webアプリ
　リダイレクト地のCSRF対策
　バックエンドサーバー都の連携
CSRF
　第三者のアカウントでログインさせられる
　第三者のソーシャルアカウントと連携され乗っ取られてしまう
対策
　通常のCSRF対策をクロスドメインでこなう必要がある
　外部サービスに引き回すStateパラメータを用いる
　ネイティブアプリとソーシャルログイン
　Token Replace Attackのリスク他のアプリ向けのAccessTokenによりアカウントのっとりが行われるかも
　バックエンドサーバーは必ずそのAccessTokenが自らのアプリに対して発行されたことを確認する
Googleの場合
　ネイティブアプリ向けSDKからWebアプリ向けのAuthorization Codeを取得できる
　ソーシャルログインによりどの機能を省略できるのか？
認証
　すべての認証
　強度の低い認証
　メールアドレス確認
　属性情報の入力
どの機能から入るか？
　既存アカウントとの連携
　新規登録
どのデバイスか？
　スマホ向けWebアプリ
　PC向けWebアプリ
　ネイティブアプリ
事例
　mixiはGoogleアカウントでログインできるようになった


「趣味開発のためのクラウド/VPS入門」
PaaSは割高
比較
　AmazonAWS
　GoogleConputeEngine
　さくらVPS
　DegitalOcean
　VULTR

 

SIerを退職し、Web系に転職しました。アフター

essay

銀行系列の中規模SIerを退職し、 受託と自社サービスの開発を行っている小規模Web系に転職することにしました という記事を書いたところ、想像以上の反響がありました。 それから一年経ったので、その後のことなど書いていこうと思います。

 

１．変わったこと

２．変わらなかったこと

３．これから

 

１．変わったこと

・COBOLとJavaAppletを書いていたかつてのシステムエンジニアはフロントエンドエンジニアになった

それっぽく言ったけどjavascriptを書く人になったということですね。今の会社はGoogleApps上でのクラウドサービスを提供していてサーバーをGAEで書いています。私はjsで書かれたフロントを主に、たまにpythonで開発をすることになりました。

 

・仕事へのモチベーションは上がった

受託で常駐で、というかつてのビジネス構造的から発生していた理不尽さが減りました。github閲覧できないとか。紙と印鑑ありきのフローであるとか。

 

・出社時間を強制されなくなった

名目ばかりではない裁量労働制になっているんだなあと思います。

 

・会社でブルックスのコーヒーがおいてあって好きに飲んでいい

大したことない感じするかもしれないが案外こういうのが日々のやる気につながってくるのだと知りました。ところでみなさんレッドブルとかは本当に今この瞬間だけがんばりたい、という時以外は飲まないほうがいいですよ。

 

・Windowsの世界で生きてきたからMacというかUnixを使うのは大変だった

右クリから空のファイル作ったりできなくてつらいとか、SSどうやって撮るのとか、そもそもこのコマンドボタンというものは一体なんなんだ？とかありました。そして開発に関する作業は結局ターミナルからやるのがいいのだと思い至ります。昔はCOBOLをコンパイルするときくらいしか黒い画面触らなかったものなのですがね。ただしエディタはIDE。

 

・昔のような方眼紙の設計書はなくなった

もちろん設計書自体がないわけではなく、プログラムの処理を日本語で書いたいわゆる詳細設計書がなくなりました。納品とかありませんし。 ドキュメント的に残すのはサーバーはAPI仕様、クライアントは特にまとまったものはなく、あとはソースとかモデルのコメントみてね、という感じです。最初は何から手を付けていいかわからなくて途方に暮れましたが、慣れると案外なんとかなります。小さく始める、を地で行けるやり方です。

 

・スケジュールだけが決まっている開発、が基本なくなった

アジャイルっぽくやっているおかげで、ストーリーとそのベロシティで線を想定しています。もちろんリリース先ぎめの物も存在しますが、その時は機能のスコープで調整します。あっこれアジャイルサムライで見たやつだ！ってなりました。

 

・ユニットテストとCIをするようになった

業務でユニットテストを書くようになりました。今までどうしてそういう現場がなかったのかと思っていましたが、ユニットテストは設計時に予めそうできるような構造しておかねばいけないのであり、そしてその技術はしっかり考えて身につけるべきものであって、なんとなくでできるものではないのだ、ということがわかりました。だから今まではそういう現場に出会わなかったのでしょう。 ユニットテストがあるので、デグレしていない証明のために全てのテストパターンを手動で１週間かけてやるというようなこともしなくてよくなったわけです。自分の書いたコードが既存の仕様を壊せばJenkinsから通知が来るのですから。

 

・手動でぽちぽちしてExcelにSSを貼るテストはやらなくなった

ユニットテストを通してあるため、手動でやるのは実際のストーリーに沿ったところだけで済みます。いわいるシステムテストのレベルです。

 

・総じて、開発時に感じる理不尽さや非合理さは以前より減った

コードで解決できることはコードで解決しようという方針が実践されていて、これがプログラマなんだなぁという気持ちになりました。

 

２．変わらなかったこと

・残業

リリース前には忙しくなり、帰るのも遅くなります。これは想定済みですし、慣れてもいるので特に所感は湧きません。

 

・絡まったスパゲッティのようで誰も手が出せないが重要なので使わざるをえないレガシーコード

想像はしていたしまあそうだよね、という感じです。でもそれが問題だと認識する素地があるし、なにかにかこつけてリファクタしたり、あわよくば作りなおそうとしていて大変よいと思います。

 

・勉強しなくてはいけないということ

覚えなくてはいけないことが多すぎてこれはもはや死ぬしかないのではとと思っていましたが、自分の及ばない部分にまで無理に手を出すのがいけないのだと気づきました。まず今業務で使っているものを理解する、しかしそれを完璧に理解しようとすると死ぬのでほどほどにする。次にその周辺を理解する、しかし完璧に理解しようとすると以下略。さらに流行りもの。しかも完璧に以下略。なのです。スーパーハッカーばかり見ていたので勘違しかけていましたが、普通の人は普通の人なりに生きて行くのがよいのです。

 

・給料

金額自体はちょっと上がったような気もしますが、かつての銀行系列子会社の福利厚生も考えるときっと下がっているでしょう。

 

・将来

かつては曲りなりに用意されてたPG→SE→PMというキャリアパスはもはや関係なくなりましたので、将来のことはわからなくなりました。

 

３．これから

変わったことと変わらなかったことも踏まえて考えると、きっと私はこの転職をしてよかったのだろうと思いました。とはいえ今もあのCOBOLとJava基幹システムやC#とExcelの業務システムを保守している人達がいるのですから、私にはできなかったことをする彼らには敬慕の念が止むことはありません。ただきっと私には合わなかったのなのだろうと思います。それに気づくのに６年かかってしまいましたが。

 

私は今年で30才になります。とても若いとは言えない年なのですから、これからどういうふうに生きていくのかも考えなくてはいけません。 ただコードを書くだけなら、アルバイトにきている学生の子の方ががよっぽどよくできます。 私はコードを書ける上に、さらに◯◯がわかる、◯◯ができるにならなければいけません。かつてのようにシステムエンジニアだったのなら、それは業務知識だということになっていたことでしょう。会計、流通、生産、在庫。 しかしもはや特定の業種の特定の業務に精通するすべはないし、するつもりもありません。私はコードを書くことでどんな問題を解決できるようになるべきなのでしょうね。 よくあるゼネラリストスペシャリストの区分ならスペシャリストの方がイメージしやすいです。いずれかの技術の領域に詳しい上に、それを自社のプロダクトにどう活かすのか、という考慮ができる人。そのプロダクトがなんなのかについてはきっと限定させない方がいいとは思いますが。

 

とはいえこれと決めてかかってそれしかやらないのも視野狭窄だと思いますし、日々の興味の先にあるものにしなければ破綻することは経験から学びました。そういう要素になりうるものを日常的に意識しなくてはいけないのだと今では思っています。

 

あまりハードよりには興味が向かないことが判明してきています。アプリケーションのよい設計とはどういうものか。保守しやすいコードはどういうものか。どんなドキュメントがあるべきなのか。どういうテストをするべきなのか。品質とはどういうことか。そういうことに興味が向いているのかもしれないと思い始めています。おそらく昔苦しめられたから。

 

でもそれはテストエンジニアになりたいのか、と言われるとと少しちがっていて、私が作ったアプリケーションが不具合や不都合がなくユーザーに対して最大限利益を与えるためにはどうすればいいのか？ということを突き詰めるべきだと考えるのがしっくりきます。 何もかっこよい意識高いアピールのために言うのではないのです。そうすれば、「私自身が最も外部から煩わされない」状態になるに違いないからです。非常に利己的な理由です。だから信じるに値する目標なのです。つまり、これを言葉にすると、「アプリケーション開発のスペシャリスト」になるのかもしれません。一気にうさんくさくなってしまいますが。

 

ところで転職以前の当時の自分のツイートなんかを見なおしてみると。当時まったくその気はなかったです。なかったののですが。どうみても病んでますねこれ。気づかないものですこわい。 かつて私は、情熱の炎を燃やすために危機感をくべました。だがそれもいずれ燃え尽きるときがきます。そのとき私は何を差し出すことになるのでしょうか。

DirectXSDKサンプルを空のプロジェクトに移す場合のプロパティ設定

directx windows

DirectSDKについているDirectX Sample BrowserでDirectxアプリのサンプルが見られる。そのコードを自分で用意したプロジェクトで動かしたいときに、どのようにプロパティを設定するか。

 

例として、Tutorial01:CreateDeviceを、VisualStudio2012で新しく作成した空のプロジェクトで動かしたい場合。

 

最低限ここをサンプルプロジェクトと同じように設定すればおそらく動く。

http://gyazo.com/0ccbfde17e44130db80f3fc3f809b90c

全般ー文字セット

 

http://gyazo.com/294fc0f667e4f4c83ff6a6b59b37883b

VC++ディレクトリーインクルードディレクトリ

VC++ディレクトリーライブラリディレクトリ

 

http://gyazo.com/3622d4ecf21b43de9cbde5bbe6d18bae

リンカー入力ー追加の依存ファイル

 

 

 

Node.js、DojoToolKit、MongoDB、Herokuでアプリを作った話

javascript dojo node.js

こちらで公開してます。

http://todo-4-you.herokuapp.com/

 

ソースはこちら。

https://github.com/arvelt/hello-nodejs

 

今回使った主なライブラリやサービス

  • Node.js
    • Express（3.X）
    • Passport
    • Mongoose
    • Mocha
    • Supertes
  • Dojo tool kit（1.9.X）
  • MongDB
  • Travis CI
  • waffle.io

 

所感

  • 最初Expressの最新を使おうとしたらPassportがまだ対応していないのかうまく動かないくてハマったので、古い方をつかうことにした。
  • angular.jsじゃなくてDojoを使ってるのは仕事で使用しているので理解を深めるため。DojoはWebページをWidgetと称するビューにして組み立てていく。
  • waffle.ioを使ってgithub issue駆動と最小git flowでやっていく。issueをTODOとして使って、対応するissueのfeatureブランチ切って、masterにPR出すということをしていた。ちょっと試したいというときにはdevlopもreleaceもいらないと思う。
  • APIに対するテストコードを書いてみる。ちょっと微妙な感じもあるが、テスト時はテスト環境のDBを初期化するようなコードをアプリ自体に持っている。NODE_ENVがtestの場合はDB状態をまっさらでテストできるようにしている。
  • Sinonを使ってクライアントテスト書こう！と意気込んでいたが、労力に成果が見合わなくなるのでSuperTestでREST API対するassertを書くことにした。RESTのつもりだけど、違うぜっていうのがあったら教えて下さい。doc.mdに仕様書いてある。というかAPI仕様を書くための標準表記法ってあったっけ。
  • Travis CIを使ったことなかったので使ってみた。むしろそのためにテストでっちあげた感じがある。ちゃんとログも見えるしなかなかおもしろい。
  • Herokuへのデプロイは手動でひと通り確認したあと、Travisからの自動アップロードへと変更した。全てのプッシュごとにデプロイされてもつらいので、masterへのpushでHerokuへデプロイするようにした。travis.ymlをちょっと変えるだけでそれだけのことができるようになり、かがくのちからってすげーという感がある。
  • TravisのCLI がよくできていて、travis setup heroku とかコマンド叩くとHerokuのAPIkeyを暗号化してtravis.ymlに載せてくれるのでほとんど何も気にしないでいけた。魔法かよ。

 

困ったところと解決案とか

 

Dojo tool kitの使い方とか

 

Dojo tool kitのdojoConfigについて

javascript dojo

ちょっとはまったので。dojoConfigについて。 

 

javascriptの勉強がてらこういうコードを書き始めている。

https://github.com/arvelt/hello-nodejs

 

サーバーをnode.js、クライアントをDojo tool kitで書いたTodoアプリ。

 

dojo tool kitを使用する場合に、dojo.jsというライブラリを読み込む必要がある。

"//ajax.googleapis.com/ajax/libs/dojo/1.9.3/dojo/dojo.js"など外部から読み込むか、dojoが提供するビルドを行い、配布用dojoパッケージを作成するかのいずれかである。

 

使用する際にはdojoConfigという値にライブラリ自体に渡す設定が行える 。

http://dojotoolkit.org/documentation/tutorials/1.9/dojo_config/

 

ここで指定したpackagesが反映されていなくてわけがわからなかったのである。

その答え。外部から読み込んだ場合には先にdojoConfigを設定してからでないと機能しない。理屈を聞けばあたりまえだが、もっとわかりやすくなってほしい。